I am using multiple domains to access liferay portal instance.
For example following are the domains mapped in hosts file of windows:
www.liferaytest1.com
www.liferaytest2.com
and in Liferay's Control Panel → Portal Settings, www.liferaytest1.com is set as virtual host.
I can access portal instance with all above mention domains along with localhost.
When I access portal with www.liferaytest1.com then I can access Guest site pages directly. Say, home is a page in Guest site then instead of accessing with www.liferatest1.com/web/guest/home I can access it directly with www.liferaytest1.com/home
So URL is shortened to some extend.
So far so good.
First Concern
Now when I try to access portal via www.liferaytest2.com and when I click any sites listed in My Sites portlet of Liferay, it redirects me to that site with the domain mentioned in virtual host i.e. www.liferaytest1.com instead of retaining www.liferaytest2.com.
Suppose I have a Site named Help, so when I click on help site link in My Sites portlet then instead of staying with www.liferaytest2.com domain it redirects me with www.liferaytest1.com domain.
This is due to virtual host mapping done in liferay.
Second Concern
When I am accessing the portal with www.liferaytest2.com and subscribe to any of the Assets then the links in email contain the virtual host domain i.e www.liferaytest1.com.
How to overcome above mention issues?
My requirement is to stay relative to the portal accessing domain.
When I access portal via www.liferaytest2.com then it should not redirect me to www.liferaytest1.com on-click of any of the Site-links as explained above and also emails that I would be getting should also be relative to the domain I am accessing i.e. www.liferaytest2.com.
First of all: You're not required to use that feature - it's implemented in a certain way (e.g. as you describe) and if that doesn't suit your needs, there's no need to configure individual virtual hosts. There's no problem serving all content through just a single virtual host or do the resolution on Apache (e.g.) - that is, fully external to Liferay. The only drawback is that you'll need the clue of the site you want to access (e.g. /web/guest as part of the URL) so that Liferay knows what content to serve.
However, you might be closer to what you'd like to achieve if you change URLs to a structure like test1.example.com and test2.example.com - this way you share at least the toplevel domain and might be able to do some cheaper single-sign-on (you can still do SSO with completely different domains)
You don't need to change the virtual host in Control Panel → Portal Setting for such requirement. Rather keep it to localhost. This will resolve both of your concerns.
Next you want to access portal using two different domain, you can do it through DNS settings. Map both to same IP (the IP of Liferay portal) and you will reach Liferay portal using any one. It will not change the url and will stay from the name initiated.
Related
Some of my apps are not working from some customers site, I later discovered that this was because I am using the default websites for my app hosting that is the url is myapp.azurewebsites.net which was not whitelisted on the customers firewall. The customer whitelisted my website domain name and its sub domain names .i.e mywebsite.com and *.mywebsite.com are all whitelisted.
If i were to create CNAME record which has a CNAME pointer to the azure default web app for example myapp.mywebsite.com points to myapp.azurewebsites.net, will this get around the issue ? Or do I need to whitelist myapp.azurewebsites.net Or its IP address that is the IP address of myapp.azurewebsites.net ?
Firstly, by default, apps hosted in App Service are accessible directly through the internet and can reach only internet-hosted endpoints. So, typically, anyone with the URL without any specific local network/firewall/proxy restrictions can access the WebApp URL.
As I understand, your WebApp is open to the public and only a few users (on a specific network), have trouble accessing the site. Plus, there are no access restrictions that you have implemented from the WebApp side.
Just to highlight,
Network administrators often deploy proxy servers, firewalls, or other
devices, which can help secure and give control over how users access
the internet. Rules designed to protect users can sometimes block or
slow down legitimate business-related internet traffic. This traffic
includes communications between you and Azure over the URLs listed
here.
Reference : Allow the Azure portal URLs on your firewall or proxy server
So, on case-case basis, for the affected network, you may have them add appservice.azure.com (Azure App Services) in the allowed list.
Or
As your customer performed – “The customer whitelisted my website domain name and its sub domain names .i.e mywebsite.com and *.mywebsite.com are all whitelisted.” have them add the URLs to allowedlist.
Or
Since IP address of your WebApp (see the reasons for the change), the best route would be for you to set up a custom domain for your WebApp.
Kindly check this doc - Tutorial: Map an existing custom DNS name to Azure App Service
The CNAME maps to the app's default hostname instead, which is less susceptible to change. | | Wildcard | *.contoso.com | CNAME record. |
-- As a side note (as indicated above), by setting up access restrictions, you can define a priority-ordered allow/deny list that controls network access to your app. Which is the opposite of your scenario, just sharing as FYI, in case you wish to know about access restrictions from WebApp side. Set up Azure App Service access restrictions
I know this may be straight forward and may have already been asked but I have been unable to get proper online articles on this or atleast I don't know how to ask google. so here's a scenerio.
I have a Windows Server which will be hosting applications.
These applications need to be accessible over the internet.
NOTE I'm aware I can just port forward and users can access the apps via a public IP. This isn't how I want it.
Users should be able to access my apps through www.my-apps.com. This domain will be registered with e.g. Godaddy, etc.
How do I go on about this ? No matter how complicated this maybe, I am ready to get my hands as dirty as possible to implement this.
You can modify the hosts file of the server hosting your site to point to the local machine's IP when visiting the www.my-apps.com domain should do it.
Open the IIS Manager, in the Connections pane of IIS, expand the Sites and select the website which you want to access via IP address.
Click on Bindings link and you will see current bindings of that website.
Click on Add button to add a new binding, On the Add Site Binding window, keep website Type as http. Select an IP address from the drop-down menu upon which you want to bind the website, then type www.my-apps.com in the Host name, click OK and then Close.
open this file: c:\Windows\System32\Drivers\etc\hosts.
Add the following entry to the file: IP Address www.my-apps.com
Save to save your changes
I have 2 separate webapi apps and I want the 1st one to be a normal webapi app which can be accessed by any authorised over the internet. With the 2nd one, I need it to not be publicly accessible and only available to the 1st (so the 2nd app is 'nested' within the first somehow).
Could anyone please tell me how I can achieve this (the apps are hosted in IIS Express at present but will be in iis for production)?
Many thanks
If you're concerned about security (and everyone should be), you can configure IIS to allow only specific computers, groups of computers or domains access to your Web site. Here's the procedure:
1)Open the IIS console and go to the Properties of your Web site.
2)double-click IP Address and Domain Restrictions.
3)Click Add Allow Entry... (on the right pane) to add an IP address or IP address range which will be allowed to access the website. Click OK.
Repeat this step to add other IP addresses to the list.
Once allowed IP addresses have been added, click Edit Feature Settings... and select Deny for Access for unspecified clients. Click OK.
Now, only users with the specified IP addresses are able to access the website.
In the next several months we will be going live with a web app ('MyApp') that is being hosted on Azure. We have purchased the MyApp.com domain and our Azure domain name is MyApp.azurewebsites.net.
We do not want our users to ever see the azure domain name in any form. We want them to see www.MyApp.com or www.MyApp.com/Sales/ViewSale etc.
I think I know how to map www.MyApp.com to MyApp.azurewebsites.net based on this article. We won't be able to set this up for a while, so I'd like to know what the user will see in their browser URL when they go to www.MyApp.com. Will they see www.MyApp.com or MyApp.azurewebsites.net? And then what will they see as they navigate various pages in the app?
Your azure website needs to be at least at the 'shared' level. This is the first tier of 'paid' azure website hosting. You do this under website > scale.
app service plan pricing tier = shared.
then you would choose 'configure' and look for 'domains' and add your www.myapp.com domain.
Then you head out to your DNS manager and add a CNAME record that directs traffic from www.myapp.com to myapp.azurewebsites.com, OR you can lookup up the Virtual (public) IP of your azure website and update the A record in your DNS manager.
Either route, your visitors will see www.myapp.com/mypage, www.myapp.com/mypage2, etc.
Once you have the proper hosting level (the control panel will tell you, look for custom domains) and configuration, they can access it as www.myapp.com. You may need to provide your own SSL cert in order to configure it as well.
When it comes time to SSL, check out this post (Azure SSL Certificate) that I made regarding uploading of SSL certs in the control panel. It will save you a headache.
The article you linked appears to have solid information based upon my recent experiences. One thing to note: It has screen shots from the old configuration panel, so some things may look different in the new one.
I haven't found a way to hide the myapp.azurewebsites.com method to access a page, other than maybe doing a redirect inside your code. However, until you have your DNS setup it might be nice to see things working under that domain to start.
I've installed a php application that requires to set up 2 virtual hosts, one for the front-end website and one for the admin panel website. The proper configuration should be as follow:
Virtual host 1 www.domain.com path:Site/src/site/public
Virtual host 2 admin.domain.com path:Site/src/site/admin/public
On Windows Azure I did as follow:
I added 2 custom domains: www.domain.com and admin.domain.com
I added a new virtual application under the "virtual applications and directories" area and now I have these 2 virtual applications:
/ site\wwwroot\Site\src\site\public
/admin site\wwwroot\Site\src\site\admin\public
When I open the address www.domain.com I see what I'm supposed to see as front end website. If I open the address www.domain.com/admin the admin panel is not working properly because it's supposed to be set up as subdomain and not as subdirectory.
Now I need to map http://www.domain.com/admin so that il looks like http://admin.domain.com
Any ideas of what needs to be done to make this type of configuration work on Azure Web Sites?
Yes, you're not configuring things at the right level. In fact, the good news is that you don't have to configure much of anything when it comes to virtual hosts / virtual applications; Azure Web Sites are already virtual in that way and run on shared instances pools.
In free/shared mode, you share instances with other users, in reserved/standard mode your sites only share instances with your other sites in the same subscription and same region (data center).
All this means that you can create as many Azure Web Sites as you need, and they will all run on the same instance (at least until they need to be scaled out, which is automatic).
In your case, you'll have two Azure Web Sites: domain-www and domain-admin. The former will be bound to www.domain.com and the latter to admin.domain.com. Of course, the names of the sites are completely arbitrary, you don't have to follow any kind of convention (though it may help).