Univention Bugzilla – Bug 44371
Portal entries have incorrect (=internal) IP address links on EC2 instances
Last modified: 2017-08-22 11:47:20 CEST
At least when portal entry objects are created by parsing UCR variables, the udm objects 'link' attribute is contructed overly complicated: By default 4 link attributes are generated:
This at least breaks scenarios where a different external DNS name than the FQDN is used. Example: I use https://ec2-xx-yy-zz-aa.eu-west-1.compute.amazonaws.com/univention/portal to access the UCS instance, but the portal links point to https://master.ucs.local/<link>...
To fix it as a workaround, i deleted all links at the portal_entry object, created a new one, and set it to "/<link>". That worked for all access scenarios.
After discussing this further, the workaround will only work for single master instances. The ip adresses and hostnames are added, because the app may be installed on another host in the domain, and the portal is only visible by default on the DC master
It will only affect the installed domains with a different DNS name.
So, I think we should be able to overwrite the default for example by setting a UCR variable. Would it be enough?
Problems with links to Apps on Amazon instances has also been reported at Ticket#2017042521000661. This is a generic problem with Amazon EC2 instances.
The same problem also exists for instances with multiple IP addresses. In this case, only eth0 is considered which, however, might be an internal IP address that is not accessible for users outside.
(In reply to Stefan Gohmann from comment #2)
> It will only affect the installed domains with a different DNS name.
> So, I think we should be able to overwrite the default for example by
> setting a UCR variable. Would it be enough?
Having a system in a DMZ which is accessed from outside is also a not uncommon scenario (cf. Bug 44524).
QA: Please install univention-portal-test and go to /univention/portal/test.html to verify the correctness of my changes.
r81867 | Bug #44371: Try to make portal links relative if server FQDN matches
r81843 | Bug #44371: Rank all links of a portal entry and chose best match
r81870 | Bug #44371: added yaml file
Some explanations to the implemented solution.
For each portal entry, its given links will be examined. If there is one link that matches the FQDN of the local server, the link will be converted to a relative link (e.g., http://foo.bar.com/test → /test).
Otherwise, all available links of a particular portal entry are ranked w.r.t. a 4-dimensional score s = (s1, s2, s3, s4). The parts of the score vector are computed as:
s1 = 1 if the link is a relative link;
s2 = 0 if the address in the browser address bar or the link refer to an FQDN;
number of matching characters when comparing the normalized (*) IP (v4 or
v6) addresses of the browser address bar and the link, otherwise
(*) Normlized in the way that zeros in IPv6 addresses are explicitly expanded (i.e., 1:2:: → 0001:0002:0000:0000:0000:0000:0000:0000), and embedded IPv4 addresses are converted to their hexadecimal form. IPv4 addresses are also converted to the corresponding hexadecimal form (i.e. 18.104.22.168 → 0102:0304).
s3 = score w.r.t. the host type according to the following matrix:
Browser address bar
| FQDN | IPv4 | IPv6
/ FQDN | 4 | 1 | 1
link < IPv4 | 2 | 4 | 2
\ IPv6 | 1 | 2 | 4
s4 = score w.r.t the protocol type according to the following matrix:
Browser address bar
| https | http
/ "//" | 4 | 4
link < https | 2 | 1
\ http | 1 | 2
Ports, query strings and fragments are not properly handled when generating relative links from portal entry links containing the same FQDN is the local server.
(In reply to Alexander Kläser from comment #7)
> Ports, query strings and fragments are not properly handled when generating
> relative links from portal entry links containing the same FQDN is the local
This problem has been fixed. If possible, FQDNs are shown on each link tile (also for a relative link).
r81888 | Bug #44371: Show FQDN as hostname on portal
r81887 | Bug #44371: Improve handling of ports, query strings, fragments
If you visit the portal per amazon fqdn and a portal entry links contains a link with the server fqdn, a link is generated that replaces the server fqdn with the amazon fqdn. The server fqdn link and amazon fqdn link have the same score and the amazon fqdn link is only taken as best possible link because it is at the beginning of the links list before sorting.
(In reply to Johannes Keiser from comment #9)
> If you visit the portal per amazon fqdn and a portal entry links contains a
> link with the server fqdn, a link is generated that replaces the server fqdn
> with the amazon fqdn. The server fqdn link and amazon fqdn link have the
> same score and the amazon fqdn link is only taken as best possible link
> because it is at the beginning of the links list before sorting.
Good catch. With the latest version, it should work fine
r82072 | Bug #44371: Make sure that FQDN addresses are also matched
r82077 | Bug #44371: Add test for correct FQDN matching
OK The tests are successful (scoring mechanic looks good)
OK IP and fqdn matching for best link (c#10)
OK Portal entries on an Amazon EC2 instance work now
Maybe we have a regression with this errata update. In a test environment and in a customer environment (Ticket#2017082221000178) as well, after this errata no menu is shown in the UMC using Firefox with ssl.
Clearing the browser cache solved the problem
(In reply to Christina Scheinig from comment #14)
> Maybe we have a regression with this errata update. In a test environment
> and in a customer environment (Ticket#2017082221000178) as well, after this
> errata no menu is shown in the UMC using Firefox with ssl.
> Clearing the browser cache solved the problem
sorry, wrong bug, it should be Bug 43658