Bug 44371 - Portal entries have incorrect (=internal) IP address links on EC2 instances
Portal entries have incorrect (=internal) IP address links on EC2 instances
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: Portal
UCS 4.2
Other Linux
: P5 normal (vote)
: UCS 4.2-1-errata
Assigned To: Alexander Kläser
Johannes Keiser
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2017-04-13 15:00 CEST by Erik Damrose
Modified: 2017-08-22 11:47 CEST (History)
4 users (show)

See Also:
What kind of report is it?: Bug Report
What type of bug is this?: 5: Major Usability: Impairs usability in key scenarios
Who will be affected by this bug?: 2: Will only affect a few installed domains
How will those affected feel about the bug?: 4: A User would return the product
User Pain: 0.229
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number: 2017042521000661
Bug group (optional): Error handling, Usability
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Erik Damrose univentionstaff 2017-04-13 15:00:14 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:

http(s)://$hostname.$domainname/<link>
http(s)://<ipaddress>/<link>

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.
Comment 1 Erik Damrose univentionstaff 2017-04-13 15:12:27 CEST
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
Comment 2 Stefan Gohmann univentionstaff 2017-04-18 07:29:01 CEST
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?
Comment 3 Alexander Kläser univentionstaff 2017-04-26 11:08:35 CEST
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.
Comment 4 Alexander Kläser univentionstaff 2017-05-17 10:58:52 CEST
(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).
Comment 5 Alexander Kläser univentionstaff 2017-08-07 18:13:02 CEST
Fixed.

QA: Please install univention-portal-test and go to /univention/portal/test.html to verify the correctness of my changes.

univention-portal (1.0.12-6):
r81868 | Bug #44371: Add JavaScript unit tests
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

univention-portal.yaml:
r81870 | Bug #44371: added yaml file
Comment 6 Alexander Kläser univentionstaff 2017-08-08 10:01:28 CEST
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;
     0, otherwise

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. 1.2.3.4 → 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
Comment 7 Alexander Kläser univentionstaff 2017-08-08 12:18:07 CEST
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.
Comment 8 Alexander Kläser univentionstaff 2017-08-08 13:01:01 CEST
(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
> server.

This problem has been fixed. If possible, FQDNs are shown on each link tile (also for a relative link).

univention-portal (1.0.12-7):
r81888 | Bug #44371: Show FQDN as hostname on portal
r81887 | Bug #44371: Improve handling of ports, query strings, fragments
Comment 9 Johannes Keiser univentionstaff 2017-08-11 11:37:15 CEST
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.
Comment 10 Alexander Kläser univentionstaff 2017-08-11 15:42:40 CEST
(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

univention-portal (1.0.12-8):
r82072 | Bug #44371: Make sure that FQDN addresses are also matched
Comment 11 Alexander Kläser univentionstaff 2017-08-11 15:56:54 CEST
univention-portal (1.0.12-9):
r82077 | Bug #44371: Add test for correct FQDN matching
Comment 12 Johannes Keiser univentionstaff 2017-08-11 19:29:21 CEST
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

YAML: OK
-> verified
Comment 13 Erik Damrose univentionstaff 2017-08-16 12:44:23 CEST
<http://errata.software-univention.de/ucs/4.2/135.html>
Comment 14 Christina Scheinig univentionstaff 2017-08-22 10:57:31 CEST
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
Comment 15 Christina Scheinig univentionstaff 2017-08-22 11:47:20 CEST
(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