I am struggling to setup a public website in Moqui, I am trying to have (dev-)www.example.net as the public marketing site and signup forms. Then the tennants on [tennant-name].example.net I have setup a basic component and then edited MoquiDevConf.xml, modified the webapp-list as shown below:
<webapp-list>
<webapp name="webpublic" http-port="8080" https-enabled="false">
<root-screen host="dev-www.example.net" location="component://webpublic/screen/webpublic.xml"/>
</webapp>
<webapp name="webroot" http-port="8080" https-enabled="false">
<root-screen host="^((?!dev-www.example.net).)*$" location="component://webroot/screen/webroot.xml"/>
</webapp>
</webapp-list>
I have restarted the app for the changes to take effect but all I get is an error 500 when I try and visit http://dev-www.example.net:8080/
org.moqui.BaseException: Could not find root screen for host [dev-www.example.net]
As far as I can tell Moqui is finding the component as I see this in the logs:
Added component [webpublic] at [file:/Volumes/MacHDD/Sources/atlas-moqui/runtime/component/webpublic]
Non dev-www hosts still work and I get the customary login screen so I am not sure what I am missing as this is almost a direct copy of the existing webroot?
Thanks for any help!
Sam
You probably using the same port number. Try different one (e.g. 8081) for the second one. All used ports should be different. Please see my comment as well.
My guess about why your particular configuration is not working is that the root-screen.#host attribute is always a regular expression and the URL you are using contains special characters including '-' and '.'. It should work if you escape these characters with a '\', i.e. use '.' and '-'.
That said, if you want to support virtual hosts with the same webapp root for multiple tenants you shouldn't need to declare the virtual hosts this way, this is only needed if you want a different webapp root screen (which may be what you eventually want to do).
UPDATE: With the configuration snippet above the issue is that there are multiple webapp-list.webapp elements, one with name=webroot which is the webapp used (as specified in the web.xml file in the moqui-name context-param) and the other with name=webpublic which is ignored because the configuration is found based on the name from the web.xml file.
The solution is to put both root-screen elements under the webapp element with name=webroot. Basically the way these are looked up is not arbitrary, it is explicit for the webapp name (the moqui-name context-param). If you have multiple webapps deployed they should have different moqui-name values to refer to different configurations. This would best be done in something other that Winstone, something like Tomcat. It would also stray from the documented ways of deploying Moqui, so a bit more work would need to be done. There isn't any really point in doing this, better to run everything in the same webapp with multiple root-screen elements and multiple root screens as needed.
Related
I'm new to CF workers and the wrangler publish system, and I can find very little information around my requirements within online sources, perhaps my search query is wrong, so hoping I can find some help here.
I have an NX workspace, containing 2x apps. One app is deployed into the top-level worker, and the second one should be deployed to a sub-directory in the same worker, effectively create a parent-child structure, like the following:
example.com/ -> top-level app
example.com/site2/ -> child-level app
My issue is, I do not understand where and how to define, in wrangler.toml, the /sub-directory/. Should I have 2x separate worker-sites for these? I was under the impression that, I could just update the worker (index.js) file in my single worker-site to handle /site2/ otherwise treat the request as standard?
All I would really like to know is, how can I specify that my publish should to the /site2/ sub-directory, if at all possible?
Thanks in advance.
There are a couple ways to handle this. If your code / logic in the workers for the top-level vs child-level is completely different, I'd recommend using two separate workers. Then you can configure which "routes" each worker will run on -
https://developers.cloudflare.com/workers/cli-wrangler/configuration
Worker 1 could be -
routes = ["example.com/"]
Worker 2 could be -
routes = ["example.com/site2/"]
Check this out for more details on how routing / matching behaves -
https://developers.cloudflare.com/workers/platform/routes#matching-behavior
The other way to do it would be to have a single worker, and inspect the incoming request to behave differently depending on whether the request is at the root, or at /site2/. I'd only recommend this if there are small differences between how the two sites should behave (e.g. swapping out a variable).
My goal is to have this:
.com/english-urls - English (United States)
.com.br/portuguess-urls - Portuguess (Brazil)
.com.mx/spanish-urls - Spanish (México)
...
I already have working multilingual functionality using this Language Switcher: http://www.yiiframework.com/wiki/293/manage-target-language-in-multilingual-applications-a-language-selector-widget-i18n/
And URL localization using this: http://www.yiiframework.com/wiki/55/i18n-subdomains-and-url-rules/
Any idea on how to have the multi top level domain functionality?
Thanks in advance to contribute to Yii development.
There are a few different ways you can approach this.
Parameterized host names. See the guide for details on how to set it up: http://www.yiiframework.com/doc/guide/1.1/en/topics.url#parameterizing-hostnames
Use environment variables set as part of your web server depending on the domain name being used.
I've done #1 in the past and it works pretty well. One nasty side effect comes up if you have a site that runs with SSL but your devs work with non-SSL machines. Parameterized host names require the full http:// or https:// as part of the URL rule unless you extend CUrlManager.
Another bug I hit recently occurs if you use parameterized hostnames AND a baseUrl (https://github.com/yiisoft/yii/issues/3520). Probably not something to worry about, but an FYI that it is there.
Which is why the idea of using environment variables intrigues me. You might be able to load only rule sets that match your given language, etc. but I haven't personally built a system using that approach.
Finally I got a solution!
Using this class: http://www.yiiframework.com/wiki/55/i18n-subdomains-and-url-rules/
1.- Define your top level domains list.
public $domainList = array('www.example.com.mx' => 'es', 'www.example.com' => 'en');
2.- Comment the unnesesary code.
3.- Detect SERVER_NAME and save as activeLanguage.
$languageCode = $this->domainList[$_SERVER['SERVER_NAME']];
$this->activeLanguage = $this->isSupportedLanguage($languageCode);
3.- Create the links in your header or main.
Thanks to twitter.com/atrandafir and acorncom for contribute!
I have been working on a Windows Store app where I have to support multiple configuration parameters for my app. One of the parameters is the URL the app is talking to.
For example development environment, test, acceptance and finally production.
One of the things i'm currently thinking about is what is the most efficient way of supporting all these environments with the least effort. Because there isn't some kind of config file that we can change to update these parameters I came up with some ideas. I'm curious about other options that I might have not seen.
Here are the things I came up with:
1
Adding multiple configuration to the app and than using them in code to get the correct parameter like this:
private string webserviceUrl;
#if DEV
webserviceUrl = "devUrl";
#elif TEST
webserviceUrl = "testUrl";
#endif
2
With the approach in number 1 there are a few more options available like including a config xml file bases on the configuration, or fetching configuration settings from a webservice the first time the app is running.
3
Using a branch/merge strategy and update the config files in the branch. Advantage is that the code is clean and only contains the settings it needs for the build it's created for. And the package can be build by the build server. Disadvantage is that you need to branch/merge alot.
The last option feels like the most 'clean' solution to do this. Am I missing any options, or do you have experience with any of these methods? What would you prefer?
I think the assumption is that apps in the store will always point to production.
But, in saying that, I'm facing the same issue as we're side loading the application onto devices that we control, and not using the Windows Store at all.
To answer your question, I prefer option 1.
Option 2 and the xml/json config file seems like the best option though.
The webservice option probably won't work. What webservice URL do you use? And how will it work if you want some instances pointing to different environments as they will all be fetching the config from the same URL.
Another option you might want to consider would be options in the settings charm menu. For example, use radio buttons for the environments, and allow the user to configure which environment they want to target.
The issue would be locking it down in production for end users so that it isn't modifiable any more. Perhaps once "PROD" radio is selected, all the radio buttons are then hidden.
If you're deploying the application through side loading, then these settings could probably be configured during the install process.
I'd be interested to hear other opinions as well. This is also an old question, so I'd like to know what solution you decided on implementing.
My application needs to be able to serve up static content which can be contained in a number of different places (directories and/or via the class loader). So, for example, a resource /static/file.html might be found in /dir1/file.html or /dir2/file.html; I would want it to try /dir1, and if not found there, then /dir2, and so on.
With servlets in Jetty, I can use either a HandlerList of DefaultServlet, to sequentially try to handle the request from each directory until satisfied, or even easier a single DefaultServlet with a ResourceCollection.
I can't see a way to do something similar in restlet, without writing a class to specifically do this. I could modify Directory to handle multiple sources (in a similar way to DefaultServlet with ResourceCollection), or write a new Restlet which tries each contained Restlet sequentially, until successfully handled (like HandlerList). But before I do that, am I missing another way that already exists to achieve this?
thanks,
Stuart
I confirm that Directory doesn't know how to handle multiple source directories. It would be a nice to add support for this and contribute it back.
I have successfully created WLS 10.3.5 domains using offline WLST, along the lines of readTemplate(template); set("name","DomainName"); ...
One detail remains: I need to set the "Credential" of each domain to a common random value, across all domains, for "global trust". It's the setting that's behind Console / Domain / Security / General / Advanced / "Credential"
Question: I fail to find the property (or its location?) that one needs to set for this?
FWIW, I use post-processing on config.xml file level now to inject an encrypted common value string as <credential-encrypted> , but I'd rather just set this via WLST without tweaking the resulting XML.
Thanks in advance,
Matthias
I suggest you to use createDomain() command it will be much easy to work.
createDomain('/olddoamin/path/template.jar’,’domainPath’,’user’, ‘passwd’)
For more you can see the following link:
WLST by Examples: Domain migration made simple
As you told your navigation on the console, I found on WLST navigation property location it is having in the followingpath:
wls:/offline/mydomain/SecurityConfiguration/mydomain>ls()
-rw- CredentialEncrypted ????????
It is with -rw- so you can update it right?
Hope this will help you.
Right, this works. The key is to not work on the template, but to read the doman from its domain directory. Then it's just setting the attribute CredentialEncrypted:
readDomain(domain_dir)
cd('/SecurityConfiguration/' + 'domain_name)
set('CredentialEncrypted', encrypt(shared_credential,domain_dir))
updateDomain()
closeDomain()
shared_credential should be something random. I used a hex-encoded digest of the newly-created config.xml file, which contains enough randomness.