lemonldap-ng issueshttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues2023-10-04T14:58:22Zhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3016'Bad token' error is returned if just a regexp is employed to define serviceT...2023-10-04T14:58:22ZChristophe Maudouxchrmdx@gmail.com'Bad token' error is returned if just a regexp is employed to define serviceToken scope### Affected version
Version: All
Platform: All
### Summary
ServiceToken scope can be defined by listing VH or by setting a regexp.
If just a regexp is used, serviceToken is not valid.
### Logs
```
2023-09-27T10:56:29+02:00 [info]...### Affected version
Version: All
Platform: All
### Summary
ServiceToken scope can be defined by listing VH or by setting a regexp.
If just a regexp is used, serviceToken is not valid.
### Logs
```
2023-09-27T10:56:29+02:00 [info] New request Lemonldap::NG::Handler::Server::Nginx GET /ws/interrogation/v1/sia
2023-09-27T10:56:29+02:00 [debug] Found token: Ncs3DVXOWIHKELrPG5hrbRPjBBsxpEIczn7yeTR8/rpvna6NXiwvsOzYUAUFM9wBJJn+9fLs8PcaSabSkVbzEGwE+bGFuDrgNtG3bw6lnu1FNo51eu9Ziwlu52afQ5E59rqhNLrHO10qfgJaxNW4cSN0RnETh9o1fUnr481yzndEPNLTkamqZKuk4tc5fjGsPyBryfF+JssJ3Kd+3P3xvw==
2023-09-27T10:56:29+02:00 [debug] Found epoch: 1695804950
2023-09-27T10:56:29+02:00 [debug] Found _session_id: 309701221aef41a79a20c63ef167c17e2f41d145702d2c9a879ddd72cf616881
2023-09-27T10:56:29+02:00 [debug] Found VHost regexp: federation?.dvsso.gendarmerie.fr
2023-09-27T10:56:29+02:00 [error] Bad service token
2023-09-27T10:56:29+02:00 [debug] [error] Bad service token
```
### Possible fixes
Fix test
```
unless ( (@vhostRegexp or @vhosts) and $_session_id ) {
```2.18.0Christophe Maudouxchrmdx@gmail.comChristophe Maudouxchrmdx@gmail.comhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2998[Security:low][CVE-2023-44469] SSRF vulnerability in OIDC SSO2023-09-29T08:40:43ZMike Lorang[Security:low][CVE-2023-44469] SSRF vulnerability in OIDC SSO### Affected version
Version: lemonldap-ng 2.16.2-1
Platform: Apache
### Summary
The vulnerability is very similar to other implementations of OIDC.
The SSRF occurs, when changing the request_uri parameter in the url.
Here is a blog...### Affected version
Version: lemonldap-ng 2.16.2-1
Platform: Apache
### Summary
The vulnerability is very similar to other implementations of OIDC.
The SSRF occurs, when changing the request_uri parameter in the url.
Here is a blogpost describing similar issues in other implementations:
https://security.lauritz-holtmann.de/post/sso-security-ssrf/
### Details
Here is the GET request in detail:
```
GET /oauth2/authorize?client_id=<redacted>&nonce=<redacted>&redirect_uri=<redacted>&response_type=code&scope=openid%20profile%20email&state=<redacted>&request_uri=https://attacker_url.com/requesturi.jwt HTTP/1.1
Host: auth.sso.domain.com
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/117.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://gitlab.int.govcert.etat.lu/
DNT: 1
Connection: close
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-site
Sec-Fetch-User: ?1
Authorization: Negotiate
<some base64 redacted>
Cookie: lemonldappdata=<redacted>
```
A request containing the parameter request_uri set to an arbitrary URL value https://attacker_url.com/requesturi.jwt was sent to the OpenID Authorization Server. As consequence the OpenID Provider interacts with the remote attacker server listening on the specified URL demonstrating that it is vulnerable to SSRF blind issues.
### Possible fixes
For security reasons the URI value of request_uri parameter should be carefully validated at server-side, otherwise an attacker could be able to lead the OpenID Provider to interact with an arbitrary server under is control and then potentially exploit SSRF vulnerabilities. It is advisable to define a strict whitelist of allowed URI values (pre-registered during the OpenID client registration process) for the request_uri parameter.2.17.1Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3009Apache2 handler not compatible with mod_remoteip2023-09-28T06:45:17ZMaxime BessonApache2 handler not compatible with mod_remoteip### Affected version
Version: 2.17.0
### Summary
* Configure Apache2 + handler
* Configure mod_remoteip to set IP address from X-Forwarded-For
* LemonLDAP still uses the proxy's address in $req, which means logs are wrong and rules b...### Affected version
Version: 2.17.0
### Summary
* Configure Apache2 + handler
* Configure mod_remoteip to set IP address from X-Forwarded-For
* LemonLDAP still uses the proxy's address in $req, which means logs are wrong and rules based on $ENV{REMOTE_ADDR} don't work
### Logs
```
[perl:debug] [pid 2057] Redirect PROXY.IP.ADDR to portal (url was /)
```
### Possible fixes
Use undocumented $r->useragent_ip instead of $r->connection->remote_ip
This will cause a change in behavior that must be mentionned in release notes2.18.0Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3003[Security:low] Open redirection when OIDC RP isn't configured with redirectio...2023-09-25T14:46:11ZYadd[Security:low] Open redirection when OIDC RP isn't configured with redirection uriThis can't happen if configuration was modified using the manager _(a test filters this case)_.
The issue is: if this misconfiguration exists, LLNG follows redirection given in redirect_uri parameter.This can't happen if configuration was modified using the manager _(a test filters this case)_.
The issue is: if this misconfiguration exists, LLNG follows redirection given in redirect_uri parameter.2.17.1YaddYaddhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3001Conf::LDAP options in lemonldap-ng.ini overrides Auth options in portal2023-09-25T09:57:06ZMaxime BessonConf::LDAP options in lemonldap-ng.ini overrides Auth options in portal### Affected version
Version: 2.17.0
### Summary
* Define a LDAP server for configuration storage
* Use a different LDAP server (AD) for Auth
* Auth is performed against the configuration LDAP server :x:
### Logs
```
[debug] Proce...### Affected version
Version: 2.17.0
### Summary
* Define a LDAP server for configuration storage
* Use a different LDAP server (AD) for Auth
* Auth is performed against the configuration LDAP server :x:
### Logs
```
[debug] Processing getUser
[debug] Try to build new LDAP connection with: ldap://ldap-config
[error] Error when binding to LDAP server: Invalid credentials
```
### Possible fixes
This is a regression caused by be157d5de17116d9bdcd25462676d399d9bf0559
we should roll back the fixes for #2711 and try to find a better solution
I think this issue might affect a decent number of users, a 2.17.1 may be justified2.17.1Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2758[CVE-2022-37186] Session destroyed on portal but still valid on handlers whil...2023-09-22T14:13:30ZMickael Bride[CVE-2022-37186] Session destroyed on portal but still valid on handlers while there is activity### Concerned version
Version: %2.0.13
Platform: Apache
### Summary
I have activated "One session per user" option.
If I log in a second time with the same account, the 1st session is well destroyed on portal, but on handler, the ses...### Concerned version
Version: %2.0.13
Platform: Apache
### Summary
I have activated "One session per user" option.
If I log in a second time with the same account, the 1st session is well destroyed on portal, but on handler, the session is still valid even after the cache expiration (600s). Session expires on handler only after 600s of inactivity (no request), while it should expire after 600s (with or without activity)
### Logs
When query is accepted by handler (just after the session was destroyed on session backend):
```
[Fri May 13 13:49:22.382959 2022] [perl:debug] [pid 21187] Apache2.pm(14): Get session 6e29421e589869bc4124bc05aa62bdb20da615f2be290a6e48 from Handler::Main::Run
[Fri May 13 13:49:22.383085 2022] [perl:debug] [pid 21187] Apache2.pm(14): Check session validity from Handler
[Fri May 13 13:49:22.383184 2022] [perl:debug] [pid 21187] Apache2.pm(14): Session timeout -> 72000
[Fri May 13 13:49:22.383288 2022] [perl:debug] [pid 21187] Apache2.pm(14): Session timeoutActivity -> 900s
[Fri May 13 13:49:22.383380 2022] [perl:debug] [pid 21187] Apache2.pm(14): Session _utime -> 1652449119
[Fri May 13 13:49:22.383465 2022] [perl:debug] [pid 21187] Apache2.pm(14): now -> 1652449762
[Fri May 13 13:49:22.383551 2022] [perl:debug] [pid 21187] Apache2.pm(14): _lastSeen -> 1652449119
[Fri May 13 13:49:22.383638 2022] [perl:debug] [pid 21187] Apache2.pm(14): now - _lastSeen = 643
[Fri May 13 13:49:22.383732 2022] [perl:debug] [pid 21187] Apache2.pm(14): Session timeoutActivityInterval -> 250
[Fri May 13 13:49:22.383822 2022] [perl:debug] [pid 21187] Apache2.pm(14): Session TTL = 71357
[Fri May 13 13:49:22.407127 2022] [perl:debug] [pid 21187] Apache2.pm(14): Update _lastSeen with 1652449762
[Fri May 13 13:49:22.407431 2022] [perl:debug] [pid 21187] Apache2.pm(14): No URL authentication level found...
[Fri May 13 13:49:22.407566 2022] [perl:debug] [pid 21187] Apache2.pm(14): api-mediation.dev.flexiblecontactcenter.orange-business.com: Apply default rule
```
After 600 seconds of inactivity:
```
[Fri May 13 14:16:08.247736 2022] [perl:info] [pid 21397] Session 6e29421e589869bc4124bc05aa62bdb20da615f2be290a6e48 can't be retrieved
[Fri May 13 14:16:08.247859 2022] [perl:info] [pid 21397] Session cannot be tied: Object does not exist in the data store at /usr/share/perl5/vendor_perl/Apache/Session/Store/DBI.pm line 93.\n
```
### Backends used
I have the following settings:
- Session timeout: 72000
- Sessions activity timeout: 900
- Sessions update interval: 250
- Sessions Storage / cache module options / default_expires_in: 600
### Possible fixes2.0.15YaddYaddhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2832[Security:medium] Redirection URL validation bypass using credentials in URL2023-09-22T14:13:30ZClément OUDOT[Security:medium] Redirection URL validation bypass using credentials in URLAn attacker can forge a redirection on a malicious site using a fake credentials in URL value.
Example:
* Portal : https://auth.openid.club
* Allowed application : https://test1.openid.club
* Malicious site : https://google.fr
* Malicio...An attacker can forge a redirection on a malicious site using a fake credentials in URL value.
Example:
* Portal : https://auth.openid.club
* Allowed application : https://test1.openid.club
* Malicious site : https://google.fr
* Malicious URL : https://test1.openid.club:test@google.fr
* Malicious URL base 64 : aHR0cHM6Ly90ZXN0MS5vcGVuaWQuY2x1Yjp0ZXN0QGdvb2dsZS5mcgo=
* Malicious redirection trigger : https://auth.openid.club/?url=aHR0cHM6Ly90ZXN0MS5vcGVuaWQuY2x1Yjp0ZXN0QGdvb2dsZS5mcgo=2.0.16Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2931[Security:medium] open redirection due to incorrect escape handling in URI us...2023-09-22T14:13:30ZMaxime Besson[Security:medium] open redirection due to incorrect escape handling in URI userinfo### Concerned version
Version: 2.16.2
### Summary
* Browse to http://auth.example.com/?url=aHR0cHM6Ly9oYWNrZXIuY29tXEBAdGVzdDEuZXhhbXBsZS5jb20v (https://hacker.com\@@test1.example.com/)
* LLNG detects it as test1.example.com, which is...### Concerned version
Version: 2.16.2
### Summary
* Browse to http://auth.example.com/?url=aHR0cHM6Ly9oYWNrZXIuY29tXEBAdGVzdDEuZXhhbXBsZS5jb20v (https://hacker.com\@@test1.example.com/)
* LLNG detects it as test1.example.com, which is allowed, and sends redirect
* For some reason, browsers "correct" it to https://hacker.com/@@test1.example.com/
### Possible fixes
We should normalize the received URL before using it in redirects:
```perl
my $u = URI->new('https://hacker.com\@@test1.example.com/');
print $u; # https://hacker.com%5C@@test1.example.com
```2.17.0Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2535[security:low] Incorrect regexp construction in isTrustedUrl lets attacker st...2023-09-22T14:13:29ZMaxime Besson[security:low] Incorrect regexp construction in isTrustedUrl lets attacker steal session on CDA application### Concerned version
Version: 2.0.11
### Summary
* Configure a CDA vhost (cda.example.com)
* let attack_urldc = base64(http://your-untrusted-domain.com/?attack=http://cda.example.com)
* Trick your target into opening http://auth.lem...### Concerned version
Version: 2.0.11
### Summary
* Configure a CDA vhost (cda.example.com)
* let attack_urldc = base64(http://your-untrusted-domain.com/?attack=http://cda.example.com)
* Trick your target into opening http://auth.lemontest.lxd/?url=attack_url
* User is redirected to http://your-untrusted-domain.com/?attack=http://cda.example.com&lemonldapcda=CDA_CODE
* You may now login to http://cda.example.com?lemonldapcda=CDA_CODE as the target user
Example:
http://auth.example.com/?url=aHR0cDovL3BlcmR1LmNvbS8/ZmFrZT1odHRwOi8vY2RhLmV4YW1wbGUuY29tLw==
### Possible fixes
the trustedDomainsRe is missing a `^`, this is also the case in !185
This mistake causes trustedDomainsRe to be easily bypassed, but CDA is the feature which has the worst impact for this mistake2.0.12Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2539[security:high, CVE-2021-35472] session cache corruption can lead to authoriz...2023-09-22T14:13:29ZChristophe Maudouxchrmdx@gmail.com[security:high, CVE-2021-35472] session cache corruption can lead to authorization bypass or spoofing### Concerned version
Version: %2.0.0 to %2.0.11
Platform: Nginx/uWSGI
### Summary
- Enable Impersonation plugin
- Enable REST Session server
- Disable CSRF tokens
- Start a terminal and execute :
for i in {1..1000}; do curl -X POST ...### Concerned version
Version: %2.0.0 to %2.0.11
Platform: Nginx/uWSGI
### Summary
- Enable Impersonation plugin
- Enable REST Session server
- Disable CSRF tokens
- Start a terminal and execute :
for i in {1..1000}; do curl -X POST -H 'Accept:application/json' -d user=msmith --data-urlencode password='msmith' http://auth.example.com:19876;done
- make reload
- Login dwho/dwho/dwho and hit F5 to refresh Portal
- Alternatively authenticated as 'dwho' or 'msmith'
### Backends used
PG![vokoscreen-2021-06-08_22-12-00](/uploads/0f9e1505bbbf02384be054e46f27c941/vokoscreen-2021-06-08_22-12-00.mp4)
### Possible fixes
Seems issue is linked to handler internal cache.
Login with 'dwho' / 'dwho'
Enable Impersonation plugin -> make reload_web_server
Start bash loop, hit F5 and session switches to 'msmith'
Stop bash loop and session is back to 'dwho' after 10/15 seconds..;2.0.12YaddYaddhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2543[security:low] 2FA bypass with sfOnlyUpgrade and totp2fDisplayExistingSecret2023-09-22T14:13:29ZMaxime Besson[security:low] 2FA bypass with sfOnlyUpgrade and totp2fDisplayExistingSecret### Concerned version
Version: 2.0.11
### Summary
* Configure "Use 2FA for session upgrade"
* Configure TOTP with "Display existing secret" enabled
* Steal a user's password and login with it
* Go to 2FA manager, click TOTP
* Scan the...### Concerned version
Version: 2.0.11
### Summary
* Configure "Use 2FA for session upgrade"
* Configure TOTP with "Display existing secret" enabled
* Steal a user's password and login with it
* Go to 2FA manager, click TOTP
* Scan the user's existing TOTP to your own device, and profit.
on backends
### Possible fixes
Either
* Remove the ability to display existing 2FA secrets
Or
* Protect existing secret from being displayed when current authentication level is too low
Depending on #25412.0.12Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2549[security:low, CVE-2021-35473] OAuth2 handler does not verify access token va...2023-09-22T14:13:29ZMaxime Besson[security:low, CVE-2021-35473] OAuth2 handler does not verify access token validity### Concerned version
Version: %2.0.4 to %2.0.11
### Summary
* Configure an OIDC client
* Configure a OAuth2 handler
* Set access token lifetime to 10 seconds
* Use Access Token from OIDC client to access the OAuth2 handler => works
...### Concerned version
Version: %2.0.4 to %2.0.11
### Summary
* Configure an OIDC client
* Configure a OAuth2 handler
* Set access token lifetime to 10 seconds
* Use Access Token from OIDC client to access the OAuth2 handler => works
* Wait 30 seconds
* Use Access Token from OIDC client to access the OAuth2 handler => *WORKS*
* /userinfo or /introspection correctly show that the token is expired
### Logs
```
[debug] Found OAuth2 access token 597d0faa693e96f08823e73164c87366b586104f575dcc648cf7b90a88b8988e
[debug] Get OIDC session 597d0faa693e96f08823e73164c87366b586104f575dcc648cf7b90a88b8988e
# missing validation here
[debug] Get user session id 59941a30e71df1c86fb05e14eec697264ca38311b18c082731230af6f23f8787
```2.0.12Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2477[security:low] Wildcard in virtualhost allows being redirected to untrusted d...2023-09-22T14:13:29ZAndreas Deschka[security:low] Wildcard in virtualhost allows being redirected to untrusted domainsOne of our users has reported to us the following security problem, which could be used for phishing.
In Lemonldap 2.0.10 when you create a virtual host with a wildcard, for example `*.subdomain.local.test`, an attacker can forward user...One of our users has reported to us the following security problem, which could be used for phishing.
In Lemonldap 2.0.10 when you create a virtual host with a wildcard, for example `*.subdomain.local.test`, an attacker can forward users to every domain by using specially designed urls.
Target url: `https://google.com#abc.subdomain.local.test/` (The slash at the end is important.)
Base64 encoded: `aHR0cHM6Ly9nb29nbGUuY29tI2FiYy5zdWJkb21haW4ubG9jYWwudGVzdC8=`
Url which the user clicks on (looks like it is safe to use): `https://myportal.local.test/url=aHR0cHM6Ly9nb29nbGUuY29tI2FiYy5zdWJkb21haW4ubG9jYWwudGVzdC8=`
User will now get redirected to `https://google.com#abc.subdomain.local.test`
I checked if cda is also affected, but from what I saw, it seems to be not. (We anyway do not have it activated.) The following line always rejects correctly:
https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/blob/v2.0/lemonldap-ng-portal/lib/Lemonldap/NG/Portal/Plugins/CDA.pm#L29
I have no problems, with publishing this issue, when you do not have anything against it.
I used chrome version 88.0.4324.192 for testing.2.0.12YaddYaddhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2495[security:medium] XSS on register form2023-09-22T14:13:29ZClément OUDOT[security:medium] XSS on register formIn register form, we do not check XSS attack before registering data into session:
```perl
# Use submitted value
$req->data->{registerInfo}->{mail} = $req->param('mail');
$req->data->{registerInfo}->{firstnam...In register form, we do not check XSS attack before registering data into session:
```perl
# Use submitted value
$req->data->{registerInfo}->{mail} = $req->param('mail');
$req->data->{registerInfo}->{firstname} = $req->param('firstname');
$req->data->{registerInfo}->{lastname} = $req->param('lastname');
$req->data->{registerInfo}->{ipAddr} = $req->address;
```
This allow to inject HTML code in form that will be displayed in mail for the end user, and can lead to malicious information (redirection on a hacker's site).
We should check for XSS before registering data, for example:
```perl
# Check input
if ( $self->p->checkXSSAttack('mail', $req->param('mail') ) or $self->p->checkXSSAttack('firstname', $req->param('firstname') ) or $self->p->checkXSSAttack('lastname', $req->param('lastname') ) ) {
$self->logger->error("XSS on Register form");
return PE_MALFORMEDUSER;
}
# Use submitted value
$req->data->{registerInfo}->{mail} = $req->param('mail');
$req->data->{registerInfo}->{firstname} = $req->param('firstname');
$req->data->{registerInfo}->{lastname} = $req->param('lastname');
$req->data->{registerInfo}->{ipAddr} = $req->address;
```
A review on all public form should be done to check we have on other issues.2.0.12Clément OUDOTClément OUDOThttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2946userControl regexp is not applied by authSlave2023-09-22T13:59:59ZChristophe Maudouxchrmdx@gmail.comuserControl regexp is not applied by authSlave### Affected version
Version: All
Platform: All
Slave authentication module can submit an unvalid login### Affected version
Version: All
Platform: All
Slave authentication module can submit an unvalid login2.17.0Christophe Maudouxchrmdx@gmail.comChristophe Maudouxchrmdx@gmail.comhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/3010oidcServiceAllowOnlyDeclaredScopes option drop offline_access scope2023-09-20T09:26:16ZYaddoidcServiceAllowOnlyDeclaredScopes option drop offline_access scope2.17.1https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2711Cannot override configuration in lemonldap-ng.ini when value is "0"2023-09-20T09:03:18ZMaxime BessonCannot override configuration in lemonldap-ng.ini when value is "0"### Concerned version
Version: 2.0.14
### Summary
* In config, set `portalDisplayRegister=1`
* In lemonldap-ng.ini, set `portalDisplayRegister=0`
* Expected: Register button is not displayed
* Actual: Register button is displayed
##...### Concerned version
Version: 2.0.14
### Summary
* In config, set `portalDisplayRegister=1`
* In lemonldap-ng.ini, set `portalDisplayRegister=0`
* Expected: Register button is not displayed
* Actual: Register button is displayed
### Logs
In portal `reloadConf`:
* `$conf` is configuration from backend
```
%{ $self->{conf} } = %{ $self->localConfig };
...
# Load conf in portal object
foreach my $key ( keys %$conf ) {
$self->{conf}->{$key} ||= $conf->{$key};
}
```
### Possible fixes
* `||=` should probably be `//=`
* Side effects ?
* Perhaps localConf should be loaded info `$self->{conf}` after `$conf` ?
* Does this happen elsewhere?2.17.0Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2996Invalid URL for application logo in myapplications web service2023-09-15T13:46:19ZClément OUDOTInvalid URL for application logo in myapplications web serviceThe logo URL returned by /myapplications is malformed: `http:/auth.example.com//static/common/apps/demo.png`. There is a missing `/` after `http:`.
The bug was introduced in commit 6fde3a06502c0fb13375830e5e9b0ebb21c6692b
The associate...The logo URL returned by /myapplications is malformed: `http:/auth.example.com//static/common/apps/demo.png`. There is a missing `/` after `http:`.
The bug was introduced in commit 6fde3a06502c0fb13375830e5e9b0ebb21c6692b
The associated unit test is wrong, as it test the malformed value:
```
ok(
$res->{myapplications}->[0]->{Applications}->[0]->{'Application Test 1'}
->{AppLogo} eq 'http:/auth.example.com//static/common/apps/demo.png',
' Logo app1 found'
);
```
Commenting the last regexp on basePath is enough to fix the problem:
```
diff --git a/lemonldap-ng-portal/lib/Lemonldap/NG/Portal/Plugins/RESTServer.pm b/lemonldap-ng-portal/lib/Lemonldap/NG/Portal/Plugins/RESTServer.pm
index f5b760e1c..cb8b88155 100644
--- a/lemonldap-ng-portal/lib/Lemonldap/NG/Portal/Plugins/RESTServer.pm
+++ b/lemonldap-ng-portal/lib/Lemonldap/NG/Portal/Plugins/RESTServer.pm
@@ -788,7 +788,7 @@ sub myApplications {
my $basePath = $self->conf->{portal};
$basePath =~ s#/*$#/#;
$basePath .= $self->p->{staticPrefix} . '/common/apps/';
- $basePath =~ s#//+#/#;
+ #$basePath =~ s#//+#/#;
my @appslist = map {
my @apps = map {
{
```
A better solution might be found.2.17.1Clément OUDOTClément OUDOThttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2992WAYF not triggered when using SAML federation plugin + one other provider2023-09-08T13:24:45ZMaxime BessonWAYF not triggered when using SAML federation plugin + one other provider### Affected version
Version: 2.16.2
### Summary
* Set Auth=SAML
* Configure samlFederationFiles
* Configure samlDiscoveryProtocolURL/samlDiscoveryProtocolActivation
* Add one IDP (samltest.id)
* Browse to portal
* You get redirected...### Affected version
Version: 2.16.2
### Summary
* Set Auth=SAML
* Configure samlFederationFiles
* Configure samlDiscoveryProtocolURL/samlDiscoveryProtocolActivation
* Add one IDP (samltest.id)
* Browse to portal
* You get redirected to the non-federated IDP instead of the federation
### Possible fixes
getIDP assumes that having one entityID in idpList means we need to use it. But WAYF may lazy load another IDP.
We should disable this heuristic when samlFederationFiles is set
Is there a better way?2.17.1Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2912Non reproducible error when redirect to another url (SAML,..)2023-08-30T15:10:53ZWalter BenderNon reproducible error when redirect to another url (SAML,..)### Concerned version
Version: %2.16.1-1 (Ubuntu)
Platform: Various
### Summary
We updated from 2.0.13 to 2.16.1 and got an non-reproducible-error when redirecting to another url (as used for SAML authentification). Some perl process...### Concerned version
Version: %2.16.1-1 (Ubuntu)
Platform: Various
### Summary
We updated from 2.0.13 to 2.16.1 and got an non-reproducible-error when redirecting to another url (as used for SAML authentification). Some perl processes worked without problems. With higher load, we get more and more processes with "Bad URL" errors. After a restart of the service the error vanished first, but than grows up to about 50% redirection with an error message. We are not sure, what caused the error and if it's a security issue. Downgrading back to 2.0.13 solved the issue.
Hint: The same problem happenend in version 2.0.16
### Logs
```
Apr 6 18:34:05 XHOSTX LLNG[44612]: [debug] Required Params URL: URI::https=SCALAR(0x563e0fd10f40)
Apr 6 18:34:05 XHOSTX LLNG[44612]: [debug] Set CSP form-action with Params URL: URI::https=SCALAR(0x563e0fd10f40)
Apr 6 18:34:14 XHOSTX LLNG[44591]: [debug] [error] Bad URL URI::https=SCALAR(0x563e0fdd1838)
Apr 6 18:34:26 XHOSTX LLNG[44593]: [debug] [error] Bad URL URI::https=SCALAR(0x563e0fdedbb8)
Apr 6 18:36:22 XHOSTX LLNG[44589]: [debug] [error] Bad URL URI::https=SCALAR(0x563e0e9a2e38)
Apr 6 18:37:59 XHOSTX LLNG[44589]: [debug] Required urldc: URI::https=SCALAR(0x563e0de5de78)
Apr 6 18:37:59 XHOSTX LLNG[44589]: [debug] Set CSP form-action with urldc: URI::https=SCALAR(0x563e0de5de78)
Apr 6 18:37:59 XHOSTX LLNG[44589]: [debug] Required Params URL: URI::https=SCALAR(0x563e0de5de78)
Apr 6 18:37:59 XHOSTX LLNG[44589]: [debug] Set CSP form-action with Params URL: URI::https=SCALAR(0x563e0de5de78)
Apr 6 18:38:26 XHOSTX LLNG[44603]: [debug] [error] Bad URL URI::https=SCALAR(0x563e0fd74fd0)
Apr 6 18:39:47 XHOSTX LLNG[44589]: [debug] [error] Bad URL URI::https=SCALAR(0x563e0e8df388)
Apr 6 18:41:17 XHOSTX LLNG[44596]: [debug] [error] Bad URL URI::https=SCALAR(0x563e0fd9eb08)
Apr 6 18:44:16 XHOSTX LLNG[44611]: [debug] [error] Bad URL URI::https=SCALAR(0x55c915768d50)
```
### Backends used
We use redis as backend
### Possible fixes
Downgrade to former version2.17.0Maxime BessonMaxime Besson