lemonldap-ng issueshttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues2023-10-08T16:40:55Zhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2896[Security][CVE-2023-28862] AuthBasic does not handle failure correctly2023-10-08T16:40:55ZMaxime Besson[Security][CVE-2023-28862] AuthBasic does not handle failure correctly### Concerned version
Version: 2.0.16
### Summary
The AuthBasic handler works like this:
* It computes a sessionid from login+password
* If sessionid already exists in the session DB, authenticate user
* Else, try to create the corr...### Concerned version
Version: 2.0.16
### Summary
The AuthBasic handler works like this:
* It computes a sessionid from login+password
* If sessionid already exists in the session DB, authenticate user
* Else, try to create the corresponding session by sending the login+pass to the portal RESTServer plugin
However, the only required step in the login flow is `store`, if anything happens after the`store` step, AuthBasic will succeed because the fixed-id session has been successfully created, which means:
* Accounts that are supposed to be 2FA-protected are not 2FA protected when AuthBasic is used
* If a 2FA module returns an error, the *first* AuthBasic request will 401, but the *second* AuthBasic request will work correctly => *VERY CONFUSING*
* Any plugin that tries to deny session *after* the `store` step will not deny AuthBasic sessions
This is probably a security issue
### Possible fixes
If the AuthBasic login process fails (not PE_OK), we need to remove the session created by `store` and return an error
This will cause a regression: users who relied on AuthBasic working for 2FA protected account will now see failures
Possible solution: use an env variable in 2FA activation rules if desired:
```
has2f("TOTP") and not $env->{"AuthBasic"}
```
or something of that sort2.16.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/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/2434[security:medium] Headers are not deleted for unprotected or skip locations w...2022-02-18T21:26:27ZDaniel Berteaud[security:medium] Headers are not deleted for unprotected or skip locations with nginx handler### Concerned version
Version: 2.0.9
Platform: CentOS 7 (or 8), nginx 1.19.3 (openresty build, to have lua support)
### Summary
When defining a location with a unprotect rule, I expect that :
- For authenticated users, exported header...### Concerned version
Version: 2.0.9
Platform: CentOS 7 (or 8), nginx 1.19.3 (openresty build, to have lua support)
### Summary
When defining a location with a unprotect rule, I expect that :
- For authenticated users, exported headers are added to the request
- For unauthenticated user, exported headers are cleared before passing the request to the backend, to prevent unauthenticated to send arbitrary headers and fake authenticated one
This used to work as expected, when I was using apache handler (in the 1.2 era). I've just tested it again, but now I'm running the handler with nginx. Headers are not removed for unauthenticated users requests. So, for example, if the backend app recognizes users by the mean of the Auth-User header, an unauthenticated user can just send this header with any valid user name, and the app will recognize it.
(Restricting access to this bug as it's a potential serious security issue)2.0.10YaddYaddhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2290[security:high, CVE-2020-24660] Lack of URL normalization by Nginx may lead t...2020-09-11T04:14:43ZMaxime Besson[security:high, CVE-2020-24660] Lack of URL normalization by Nginx may lead to authorization bypass when URL access rules are used### Environment
LemonLDAP::NG version: 2.0.8
Operating system: Debian Stretch, Debian Buster, probably RHEL
Web server: nginx/1.10.3, nginx/1.14.2
### Summary
When using Nginx, regexp-based access rules may not be correctly enforced...### Environment
LemonLDAP::NG version: 2.0.8
Operating system: Debian Stretch, Debian Buster, probably RHEL
Web server: nginx/1.10.3, nginx/1.14.2
### Summary
When using Nginx, regexp-based access rules may not be correctly enforced by the handler.
I am doing a CVE request for this bug
### Logs
* Content of test vhost:
```
# cat /var/lib/lemonldap-ng/test/admin
SECRET ADMIN FILE
```
* Handler configuration:
![image](/uploads/eee374a6dffff959789dcf83331efb24/image.png)
* Proof of exploitation:
```
GET -S http://test1.example.com/admin/secretfile
GET http://test1.example.com/admin/secretfile
302 Moved Temporarily //AS EXPECTED
$ GET -S http://test1.example.com/%61dmin/secretfile
GET http://test1.example.com/%61dmin/secretfile
200 OK
SECRET ADMIN FILE //SHOULD BE PROTECTED
GET -S http://test1.example.com/x/../admin/secretfile
GET http://test1.example.com/x/../admin/secretfile
200 OK
SECRET ADMIN FILE //SHOULD BE PROTECTED
```
I have also successfully tested this in a reverse proxy configuration, which is a very common, if not the most common use case. I have also tested this without the "skip" keyword, in such a cas, a normal user may be granted access to admin-only resources.
### Cause
The problem comes from the fact that the handler tests regexp against the REQUEST_URI variable. Unlike Apache, Nginx does not [normalize](https://en.wikipedia.org/wiki/URI_normalization) REQUEST_URI. Because of this, it becomes extremely hard for an admin to write a regexp that correctly catches all of the possible URLs that can be used to target a protected resource (such as /admin).
### Solutions
#### URI::Normalize
Nginx transmits the original URL in a X_ORIGINAL_URL header. We could use this fact to trigger special processing in the handler:
```
$self->env->{REQUEST_URI} = $self->env->{X_ORIGINAL_URI}
if ( $self->env->{X_ORIGINAL_URI} );
```
would change to
```
$self->env->{REQUEST_URI} = normalize_url($self->env->{X_ORIGINAL_URI})
if ( $self->env->{X_ORIGINAL_URI} );
```
Using `normalize_url` from [URI::Normalize](https://metacpan.org/pod/URI::Normalize) which is not in distros but easily embeddable.
#### Nginx config
We could also make Nginx normalize the URL, with something like this:
```
location / {
...
# Save the normalized URI here
set $original_uri $uri$is_args$args;
...
}
location = /lmauth {
...
fastcgi_param X_ORIGINAL_URI $original_uri;
...
}
```
But that means each webserver we ever want to support will probably have it's own, distinct solution2.0.9Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/1630SSO cookie is sent to protected applications with Nginx-based ReverseProxy2019-02-12T20:39:21ZChristophe Maudouxchrmdx@gmail.comSSO cookie is sent to protected applications with Nginx-based ReverseProxy### Concerned version
Version: %2.0.1
Platform: Nginx
### Summary
SSO cookie is not deleted
### Possible fixes
Bad RegExp### Concerned version
Version: %2.0.1
Platform: Nginx
### Summary
SSO cookie is not deleted
### Possible fixes
Bad RegExp2.0.2Christophe Maudouxchrmdx@gmail.comChristophe Maudouxchrmdx@gmail.comhttps://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/3013Default value is not applied to ServiceTokenTTL2023-11-20T14:44:22ZChristophe Maudouxchrmdx@gmail.comDefault value is not applied to ServiceTokenTTL### Affected version
Version: %2.17.0
Platform: All
### Summary
ServiceTokenTTL can be defined for each VH by using Manager. Default value (30s) should be used if ServiceTokenTTL is set to '-1'.
But it seems that the used value is re...### Affected version
Version: %2.17.0
Platform: All
### Summary
ServiceTokenTTL can be defined for each VH by using Manager. Default value (30s) should be used if ServiceTokenTTL is set to '-1'.
But it seems that the used value is really '-1' instead of '30'.
![image](/uploads/163ed864e35800d89becc9b61c827c2f/image.png)
### Logs
```
2023-09-26T14:40:52+02:00 [info] New request Lemonldap::NG::Handler::Server::Nginx GET /rest/webservice/multifichiers
2023-09-26T14:40:52+02:00 [debug] Found token: kNW9Z7tPx5BGcedL48GqcwRkehsPxEp12mwG5mpBE+JWkCKDrx/lPQmCciSKwBwi0RMnTi1Pr4mY8Q3ud5WTMkthByb5qteYUOwfy2cZhVvX7itK8VjCNrPzXDIpMOsU75IucuR2hMU1OFA46tbSKQkCU+DJKojmH0WnIyyfrYuZASkJsnHC9IArYCtxZWyJis/7x6hBvqppWwMnBya4UA==
2023-09-26T14:40:52+02:00 [debug] Found epoch: 1695732026
2023-09-26T14:40:52+02:00 [debug] Found _session_id: 31ea82a21bad933a8a0ccf8db0b143413702043ed50ea748914e6f54b148756a
2023-09-26T14:40:52+02:00 [debug] Found VHost: fpr-test.dvsso.gendarmerie.fr
2023-09-26T14:40:52+02:00 [debug] fpr-test.dvsso.gendarmerie.fr found in VHosts list: fpr-test.dvsso.gendarmerie.fr
2023-09-26T14:40:52+02:00 [warn] Expired service token
2023-09-26T14:40:52+02:00 [debug] [warn] Expired service token
2023-09-26T14:40:52+02:00 [debug] VH: fpr-test.dvsso.gendarmerie.fr with ServiceTokenTTL: -1
2023-09-26T14:40:52+02:00 [debug] TokenTime: 1695732026 / Time: 1695732052
2023-09-26T14:40:52+02:00 [debug] No cookie found
```
### Possible fixes
SetDefault function is employed?2.18.0https://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/2984Test fails with Perl 5.382023-08-28T16:00:34ZYaddTest fails with Perl 5.38From https://bugs.debian.org/1043239 :
> Source: lemonldap-ng
> Version: 2.16.1+ds-2
> Severity: important
> Tags: ftbfs trixie sid
> User: debian-perl@lists.debian.org
> Usertags: perl-5.38-transition
>
> This package fails to build f...From https://bugs.debian.org/1043239 :
> Source: lemonldap-ng
> Version: 2.16.1+ds-2
> Severity: important
> Tags: ftbfs trixie sid
> User: debian-perl@lists.debian.org
> Usertags: perl-5.38-transition
>
> This package fails to build from source with Perl 5.38 (currently in experimental.)
>
> http://perl.debian.net/rebuild-logs/perl-5.38-throwaway/lemonldap-ng_2.16.1+ds-2/lemonldap-ng_2.16.1+ds-2_amd64-2023-08-04T06:12:12Z.build
# Failed test 'Found correct error message'
# at t/12-Lemonldap-NG-Handler-Jail.t line 114.
# 'syntax error at (eval 52) line 1, at EOF
# Execution of (eval 52) aborted due to compilation errors.
# '
# doesn't match '(?^:Missing right curly or square bracket)'
# Looks like you failed 1 test of 22.
# Failed test 'Found correct error message'
# at t/13-Lemonldap-NG-Handler-Fake-Safe.t line 107.
# 'syntax error at (eval 47) line 1, at EOF
# Execution of (eval 47) aborted due to compilation errors.
# '
# doesn't match '(?^:Missing right curly or square bracket)'
# Looks like you failed 1 test of 16.
Test Summary Report
-------------------
t/12-Lemonldap-NG-Handler-Jail.t (Wstat: 256 (exited 1) Tests: 22 Failed: 1)
Failed test: 22
Non-zero exit status: 1
t/13-Lemonldap-NG-Handler-Fake-Safe.t (Wstat: 256 (exited 1) Tests: 16 Failed: 1)
Failed test: 16
Non-zero exit status: 1
Files=25, Tests=405, 7 wallclock secs ( 0.08 usr 0.03 sys + 4.03 cusr 0.70 csys = 4.84 CPU)
Result: FAIL
> This looks like just an issue of changed diagnostics, but please don't hesitate to file a bug against perl in case it turns out to have runtime effects that warrant a Breaks entry.2.17.0https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2787Status: Unknown command line during OIDC flow2022-08-26T14:13:47ZMaxime BessonStatus: Unknown command line during OIDC flow### Concerned version
Version: 2.0.14
### Summary
* Enable handler status
* Browse to an OIDC app, or any portal URL that contains a space, such as
* Non fatal, but puzzling status error line appears in Apache error logs
* Also, the ...### Concerned version
Version: 2.0.14
### Summary
* Enable handler status
* Browse to an OIDC app, or any portal URL that contains a space, such as
* Non fatal, but puzzling status error line appears in Apache error logs
* Also, the request won't be counted
### Logs
```
Status: Unknown command line -> dwho => /oauth2/authorize?client_id=test&scope=a b 24
```
### Possible fixes
This is caused by the regexp in Status.pm
```
# Activity collect
if (
/^(\S+)\s+=>\s+(\S+)\s+(OK|REJECT|REDIRECT|LOGOUT|UNPROTECT|SKIP|EXPIRED|\-?\d+)$/
)
{
```
OIDC scopes can contain spaces
I think the best fix is to normalize the URL using URI->canonical before writing it to the status socket
Warning: status write are done in several places: Handler::Main, Portal::Main, etc.2.0.15Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2769missing handler logs with default Nginx + LemonLDAP2022-07-28T10:11:25Zdcoutadeur dcoutadeurmissing handler logs with default Nginx + LemonLDAP### Concerned version
Version: %2.0.14
Platform: Nginx
### Summary
With a default `lemonldap-ng.ini`, half of the handler logs are missing, unless the logger is specified explicitely:
```
userLogger = Lemonldap::NG::Common::Logger::...### Concerned version
Version: %2.0.14
Platform: Nginx
### Summary
With a default `lemonldap-ng.ini`, half of the handler logs are missing, unless the logger is specified explicitely:
```
userLogger = Lemonldap::NG::Common::Logger::Syslog
logger = Lemonldap::NG::Common::Logger::Syslog
```
### Workaround
Set the logger explicitely
### Resolution
More investigation needed2.0.15dcoutadeur dcoutadeurdcoutadeur dcoutadeurhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2693"Status: Unknown command line -> " log line for each SKIP and EXPIRED accesses2023-12-05T15:51:39ZJérémie Pierson"Status: Unknown command line -> " log line for each SKIP and EXPIRED accesses### Concerned version
Version: %2.0.13
Platform: Nginx
### Summary
If Status handler is enabled, for each user access through a handler, if action was SKIP or EXPIRED, a line is logged to STDERR.
As an example, this morning on one o...### Concerned version
Version: %2.0.13
Platform: Nginx
### Summary
If Status handler is enabled, for each user access through a handler, if action was SKIP or EXPIRED, a line is logged to STDERR.
As an example, this morning on one of our production system it amounts to 40,370 lines out of 43,294 total log lines of LemonLDAP::NG handler service.
### Logs
Example log line:
```
Feb 03 18:04:15 llnghost1 llng-fastcgi-server[1234]: Status: Unknown command line -> 192.168.0.27 => webapp1.example.com/path/to/a/page SKIP
```
### Possible fixes
It seems that the Status handler has to know each and every possible handler action.
Every time an action is reached in `Lemonldap/NG/Handler/Main/Run.pm`, the code calls `$class->updateStatus($req, $action, ...)`, which appears to send a line of text to the Status handler via a pipe.
In the Status handler, this line is then handled according to its match against regular expressions. One of the regexp is `/^(\S+)\s+=>\s+(\S+)\s+(OK|REJECT|REDIRECT|LOGOUT|UNPROTECT|\-?\d+)$/` (commented as "Activity collect"). It **does not** match status lines for SKIP or EXPIRED actions. Then the code falls into the catch-all case which logs unknown status lines to STDERR.
If I edit this regular expression to add the two missing actions, the spurious log lines disappear (and I see new entries in the status JSON :-) ).
Patch looks like this:
```diff
--- Lemonldap/NG/Handler/Lib/Status.pm.ori 2022-02-04 08:58:46.000000000 +0100
+++ Lemonldap/NG/Handler/Lib/Status.pm 2022-02-04 08:55:18.000000000 +0100
@@ -63,7 +63,7 @@
# Activity collect
if (
-/^(\S+)\s+=>\s+(\S+)\s+(OK|REJECT|REDIRECT|LOGOUT|UNPROTECT|\-?\d+)$/
+/^(\S+)\s+=>\s+(\S+)\s+(OK|REJECT|REDIRECT|LOGOUT|UNPROTECT|SKIP|EXPIRED|\-?\d+)$/
)
{
my ( $user, $uri, $code ) = ( $1, $2, $3 );
```
There may be other actions which we do not see in our logs, but that are also missing from the regular expression...2.0.14YaddYaddhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2632Handler::Server::Nginx does not use logger config from lemonldap-ng.ini2022-01-20T14:17:14ZMaxime BessonHandler::Server::Nginx does not use logger config from lemonldap-ng.ini### Concerned version
Version: 2.0.13
### Summary
* Using Nginx + FastCGI (Handler::Server::Nginx)
* logs using $self in this objet do not work
```
# never appears
$self->logger->debug('New request');
```
This is because the...### Concerned version
Version: 2.0.13
### Summary
* Using Nginx + FastCGI (Handler::Server::Nginx)
* logs using $self in this objet do not work
```
# never appears
$self->logger->debug('New request');
```
This is because the PSGI init() method is called without arguments, so logging gets initialized to Syslog with a default level (info)
* Because of this, it is also impossible to change the logger for the PSGI Server. (setting log4perl etc)
* However, logs emitted by Handler classes ($class->logger) work fine
### Possible fixes
in Handler/PSGI.pm:
```
sub init {
my ( $self, $args ) = @_;
$self->api('Lemonldap::NG::Handler::PSGI::Main') unless ( $self->api );
my $tmp = ( $self->Lemonldap::NG::Common::PSGI::init($args)
and $self->Lemonldap::NG::Handler::Lib::PSGI::init($args) );
return $tmp;
}
```
`Lemonldap::NG::Common::PSGI::init` is called without any args (causing the default logger to be set) because none of the child classes (Handler::Server::Nginx) reads the local config (lemonldap-ng.ini)
lemonldap-ng.ini is read during `Lemonldap::NG::Handler::Lib::PSGI::init`, so perhaps we should
* Call `Lemonldap::NG::Handler::Lib::PSGI::init` first
* Call `Lemonldap::NG::Common::PSGI::init` next, passing `$self->api->localConfig` as an argument, so that the correct logger can be set in $self->logger
What do you think @guimard ? Can changing the order of those two calls cause any trouble? Do you see another solution?2.0.14Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2618DevOps handler does not work if RULES_URL uWSGI/FastCGI parameter is set2021-09-30T15:08:21ZChristophe Maudouxchrmdx@gmail.comDevOps handler does not work if RULES_URL uWSGI/FastCGI parameter is set### Concerned version
Version: %2.0.X
Platform: All
### Summary
RULES_URL parameter can be set to retreive rules.json from another location than protected application.
But Host header is not defined depending on RULES_URL.
### Logs
...### Concerned version
Version: %2.0.X
Platform: All
### Summary
RULES_URL parameter can be set to retreive rules.json from another location than protected application.
But Host header is not defined depending on RULES_URL.
### Logs
```
package Lemonldap::NG::Handler::Lib::DevOps;
my ( $class, $req, $vhost ) = @_;
$class->logger->debug("****************** $vhost");
my $json;
if ( $class->tsv->{useSafeJail} ) {
my $rUrl = $req->{env}->{RULES_URL}
|| ( (
$class->localConfig->{loopBackUrl}
|| "http://127.0.0.1:" . $req->{env}->{SERVER_PORT}
)
. '/rules.json'
);
$class->logger->debug("################## $rUrl");
my $get = HTTP::Request->new( GET => $rUrl );
$class->logger->debug("****************** $vhost");
$get->header( Host => $vhost );
my $resp = $class->ua->request($get);
if ( $resp->is_success ) {
eval {
$json = from_json( $resp->content, { allow_nonref => 1 } ); };
if ($@) {
$class->logger->error(
"Bad rules.json for $vhost, skipping ($@)");
}
else {
$class->logger->info("Compiling rules.json for $vhost");
}
}
}
else {
$class->logger->error(
q"I refuse to compile rules.json when useSafeJail isn't activated! Yes I know, I'm a coward..."
);
}
```
```
2021-09-20T14:13:30.027+02:00 dapqssogndevops f=3 s=7 LLNG[45628]: [debug] Process 45628 calls aliasInit
2021-09-20T14:13:30.027+02:00 dapqssogndevops f=3 s=7 LLNG[45628]: [debug] Process 45628 calls oauth2Init
2021-09-20T14:13:30.028+02:00 dapqssogndevops f=3 s=7 LLNG[45628]: [debug] Lemonldap::NG::Handler::Server::Main: configuration is up to date
2021-09-20T14:13:30.048+02:00 dapqssogndevops f=3 s=7 LLNG[45628]: [debug] ****************** evengrave.dvsso.gendarmerie.fr
2021-09-20T14:13:30.048+02:00 dapqssogndevops f=3 s=7 LLNG[45628]: [debug] ################## http://devops.dvsso.gendarmerie.fr/rules.json
2021-09-20T14:13:30.051+02:00 dapqssogndevops f=3 s=7 LLNG[45628]: [debug] ****************** evengrave.dvsso.gendarmerie.fr
2021-09-20T14:14:29.806+02:00 dapqssogndevops f=3 s=7 LLNG[45627]: [debug] DevOps handler called by evengrave.dvsso.gendarmerie.fr
2021-09-20T14:14:29.806+02:00 dapqssogndevops f=3 s=7 LLNG[45627]: [debug] VH evengrave.dvsso.gendarmerie.fr is HTTPS
2021-09-20T14:14:29.812+02:00 dapqssogndevops f=3 s=7 LLNG[45627]: [debug] Get session 9deae8c00b4453092a8c6d544c4eb6a880168a2ce78a6a0156e7cf427c626aba from Handler::Main::Run
2021-09-20T14:14:29.812+02:00 dapqssogndevops f=3 s=7 LLNG[45627]: [debug] Check session validity from Handler
2021-09-20T14:14:29.812+02:00 dapqssogndevops f=3 s=7 LLNG[45627]: [debug] Session timeout -> 18000
2021-09-20T14:14:29.812+02:00 dapqssogndevops f=3 s=7 LLNG[45627]: [debug] Session _utime -> 1632131219
2021-09-20T14:14:29.813+02:00 dapqssogndevops f=3 s=7 LLNG[45627]: [debug] now -> 1632140069
2021-09-20T14:14:29.813+02:00 dapqssogndevops f=3 s=7 LLNG[45627]: [debug] Session timeoutActivityInterval -> 60
2021-09-20T14:14:29.813+02:00 dapqssogndevops f=3 s=7 LLNG[45627]: [debug] Session TTL = 9150
2021-09-20T14:14:29.813+02:00 dapqssogndevops f=3 s=7 LLNG[45627]: [debug] No URL authentication level found...
2021-09-20T14:14:29.813+02:00 dapqssogndevops f=3 s=7 LLNG[45627]: [debug] evengrave.dvsso.gendarmerie.fr: Apply default rule
2021-09-20T14:14:29.813+02:00 dapqssogndevops f=3 s=7 LLNG[45627]: [debug] Send header Auth-User with value alexandre.karim
2021-09-20T14:14:29.813+02:00 dapqssogndevops f=3 s=7 LLNG[45627]: [debug] removing cookie
2021-09-20T14:14:29.813+02:00 dapqssogndevops f=3 s=7 LLNG[45627]: [debug] Cookies -> rl_anonymous_id=%220b20876f-3594-4705-81d1-54863233e58a%22; rl_user_id=%22%22; dtCookie=3$E7299D988465464BC2DC6EC581246F3B|0d251f1d60b14756|1|65c02833dcb59b59|0; rxVisitor=1632131211503UF9PQSFTACVJUK55HSGO56N88NPVBMBQ; dtPC=3$132431880_673h-vRMSNPBNCRBKJHGKGCVBTKHMRSUARCUGH-0e0; rxvt=1632134232005|1632131211514; dtSa=false%7C_load_%7C2%7C_onload_%7C-%7C1632132432005%7C132431880_673%7Chttps%3A%2F%2Fauth2.sso.gendarmerie.fr%2Fsaml%2FsingleSignOn%7CAuthentication%20portal%7C%7C%7C; dtLatC=17; lemonldap=9deae8c00b4453092a8c6d544c4eb6a880168a2ce78a6a0156e7cf427c626aba; lemonldaphttp=a8d92881942db4991654a59d96f0e68fdce85cac094f012051e01279a6e77a895e624af56392d61a93d48d4ca05a817a; PHPSESSID=jfmaiblpl2vidgpe6s17142uj1; MYSAPSSO2=AjQxMDMBABhHADAAMAA0ADQAMAA4ADkANwAgACAAIAACAAY2ADEAMAADABBQAEUAQwAgACAAIAAgACAABAAYMgAwADIAMQAwADkAMgAwADEAMAAwADcABQAEAAAADAkAAkYA%2fwFCMIIBPgYJKoZIhvcNAQcCoIIBLzCCASsCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHATGCAQowggEGAgEBMFswTzELMAkGA1UEBhMCRlIxDTALBgNVBAoTBERHR04xDTALBgNVBAsTBERHR04xFDASBgNVBAsTC0kwMDIwNTAzNDczMQwwCgYDVQQDEwNQRUMCCAogFxITFlABMAkGBSsOAwIaBQCgXTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTA5MjAxMDA3MTJaMCMGCSqGSIb3DQEJBDEWBBRweMA2sRZfC2nPjlGzSVSH5NL21DAJBgcqhkjOOAQDBC8wLQIUBFWNqTQxUh8dax64VUJTkXh6mJ4CFQCl5YsLSsIEV3cPOwnL4idlUAqFvw%3d%3d
2021-09-20T14:14:29.813+02:00 dapqssogndevops f=3 s=7 LLNG[45627]: [debug] CookieName -> lemonldap
2021-09-20T14:14:29.814+02:00 dapqssogndevops f=3 s=7 LLNG[45627]: [debug] newCookies -> rl_anonymous_id=%220b20876f-3594-4705-81d1-54863233e58a%22; rl_user_id=%22%22; dtCookie=3$E7299D988465464BC2DC6EC581246F3B|0d251f1d60b14756|1|65c02833dcb59b59|0; rxVisitor=1632131211503UF9PQSFTACVJUK55HSGO56N88NPVBMBQ; dtPC=3$132431880_673h-vRMSNPBNCRBKJHGKGCVBTKHMRSUARCUGH-0e0; rxvt=1632134232005|1632131211514; dtSa=false%7C_load_%7C2%7C_onload_%7C-%7C1632132432005%7C132431880_673%7Chttps%3A%2F%2Fauth2.sso.gendarmerie.fr%2Fsaml%2FsingleSignOn%7CAuthentication%20portal%7C%7C%7C; dtLatC=17; PHPSESSID=jfmaiblpl2vidgpe6s17142uj1; MYSAPSSO2=AjQxMDMBABhHADAAMAA0ADQAMAA4ADkANwAgACAAIAACAAY2ADEAMAADABBQAEUAQwAgACAAIAAgACAABAAYMgAwADIAMQAwADkAMgAwADEAMAAwADcABQAEAAAADAkAAkYA%2fwFCMIIBPgYJKoZIhvcNAQcCoIIBLzCCASsCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHATGCAQowggEGAgEBMFswTzELMAkGA1UEBhMCRlIxDTALBgNVBAoTBERHR04xDTALBgNVBAsTBERHR04xFDASBgNVBAsTC0kwMDIwNTAzNDczMQwwCgYDVQQDEwNQRUMCCAogFxITFlABMAkGBSsOAwIaBQCgXTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMTA5MjAxMDA3MTJaMCMGCSqGSIb3DQEJBDEWBBRweMA2sRZfC2nPjlGzSVSH5NL21DAJBgcqhkjOOAQDBC8wLQIUBFWNqTQxUh8dax64VUJTkXh6mJ4CFQCl5YsLSsIEV3cPOwnL4idlUAqFvw%3d%3d
2021-09-20T14:14:29.814+02:00 dapqssogndevops f=3 s=7 LLNG[45627]: [debug] User alexandre.karim was granted to access to /
2021-09-20T14:14:29.814+02:00 dapqssogndevops f=3 s=7 LLNG[45627]: [debug] Check configuration for Lemonldap::NG::Handler::Server::Main
2021-09-20T14:14:29.814+02:00 dapqssogndevops f=3 s=7 LLNG[45627]: [debug] Get configuration from cache without verification.
2021-09-20T14:14:29.814+02:00 dapqssogndevops f=3 s=7 LLNG[45627]: [debug] Lemonldap::NG::Handler::Server::Main: configuration is up to date
2021-09-20T14:14:29.814+02:00 dapqssogndevops f=3 s=6 LLNG[45627]: [info] No cookie found
2021-09-20T14:14:29.814+02:00 dapqssogndevops f=3 s=7 LLNG[45627]: [debug] Build URL https://evengrave.dvsso.gendarmerie.fr/rules.json
```
### Possible fixes
$req->{env}->{RULES_URL} is called (devops.dvsso.gendarmerie.fr/rules.json):
my $get = HTTP::Request->new( GET => $rUrl );
But, HTTP_HOST header is set with protected application alias (evengrave.dvsso.gendarmerie.fr):
$get->header( Host => $vhost );
Host header must be set with $req->{env}->{RULES_URL} corresponding host.2.0.14Christophe Maudouxchrmdx@gmail.comChristophe Maudouxchrmdx@gmail.comhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2568SafeJail does not report errors correctly2021-07-26T16:19:13ZMaxime BessonSafeJail does not report errors correctly### Concerned version
Version: %2.0.12
### Summary
* Use an invalid expression in a rule somewhere (header, macro, etc)
* With useSafeJail=0, the error is correctly reported
* With useSafeJail=1, the error is empty
### Logs
Example ...### Concerned version
Version: %2.0.12
### Summary
* Use an invalid expression in a rule somewhere (header, macro, etc)
* With useSafeJail=0, the error is correctly reported
* With useSafeJail=1, the error is empty
### Logs
Example with a classic mistake, using "$uid@example.com" in a header value:
useSafeJail=0:
```
[error] syntax error at (eval 300) line 1, near "}@example"
Global symbol "@example" requires explicit package name (did you forget to declare "my @example"?) at (eval 300) line 1.
[error] Lemonldap::NG::Handler::PSGI::Main Unable to forge test1.lemontest.lxd headers: syntax error at (eval 300) line 1, near "}@example"
Global symbol "@example" requires explicit package name (did you forget to declare "my @example"?) at (eval 300) line 1.
```
useSafeJail=1
```
[error]
[error] Lemonldap::NG::Handler::PSGI::Main Unable to forge test1.lemontest.lxd headers:
```
### Possible fixes
I found this in Handler::Main::Jail
```
eval { $res = ( $self->jail->reval($reval) ) };
if ($@) {
$self->error($@);
return undef;
}
```
It seems that the eval here is unnecessary: the Jail CPAN module already handles failure in reval(), and we also do it in our Fake Jail implementation (see sub reval in Handler::Main::Jail)
removing this eval lets the error be correctly reported :
```
#already evals
$res = ( $self->jail->reval($reval) );
if ($@) {
$self->error($@);
return undef;
}
```
@guimard do you remember why/if the eval in the above code is needed?2.0.13Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2481missing _utime in OIDC Client Credential sessions2021-03-10T20:37:03ZMaxime Bessonmissing _utime in OIDC Client Credential sessions### Concerned version
Version: %2.0.11
Platform: (Nginx/Apache/Node.js)
### Summary
* Sessions created by client credential grands are missing a _utime
* Because of this, OAuth2 handler does not work
* And client credential sessions ...### Concerned version
Version: %2.0.11
Platform: (Nginx/Apache/Node.js)
### Summary
* Sessions created by client credential grands are missing a _utime
* Because of this, OAuth2 handler does not work
* And client credential sessions will not be purged
### Logs
```
Can't use string ("0") as a HASH ref while "strict refs" in use at /usr/share/perl5/Lemonldap/NG/Handler/Lib/OAuth2.pm line 15
```2.0.12Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2417Error in cookie name used by lemonldap regexp2020-12-21T19:08:15Zandy tanError in cookie name used by lemonldap regexp### Concerned version
Version: 2.0.9
Platform: (Nginx/Apache/Node.js)
### Summary
Basically if you enable sticky sessions on your lb with a cookie name based on lemonldap cookie (ex: sticky-lemonldap)
lemon will not be able to work a...### Concerned version
Version: 2.0.9
Platform: (Nginx/Apache/Node.js)
### Summary
Basically if you enable sticky sessions on your lb with a cookie name based on lemonldap cookie (ex: sticky-lemonldap)
lemon will not be able to work and retrieve session
### Logs
```
[lemonldap-9b5c47b75-xwzc7] [Wed Dec 16 11:01:05 2020] [LLNG:39] [info] Session
http://10.2.1.47:80
can't be retrieved
[lemonldap-9b5c47b75-xwzc7] [Wed Dec 16 11:01:05 2020] [LLNG:39] [info] Session cannot be tied: Invalid session ID:
http://10.2.1.47:80
at /usr/share/perl5/Apache/Session/Generate/MD5.pm lin
e 42, <DATA> line 153.
[lemonldap-9b5c47b75-xwzc7]
```
### Backends used
For any bug on configuration/sessions storage, give us details on backends
### Possible fixes
Fix the current regexp used to match specific words/ real cookie name setup in manager2.0.10Christophe Maudouxchrmdx@gmail.comChristophe Maudouxchrmdx@gmail.comhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2387logout does not clear handler cache2020-12-21T15:33:24ZMaxime Bessonlogout does not clear handler cache### Concerned version
Version: 2.0.9
Platform: Apache
### Summary
* Have a portal server and a **SEPARATE** handler server
* Create a CDA vhost with a logout rule
* Logout from CDA vhost
* Logout does not remove the CDA cookie, and h...### Concerned version
Version: 2.0.9
Platform: Apache
### Summary
* Have a portal server and a **SEPARATE** handler server
* Create a CDA vhost with a logout rule
* Logout from CDA vhost
* Logout does not remove the CDA cookie, and handler cache is not purged on the handler server, CDA session remains valid for a few minutes
### Logs
This code in Handler/Main/Run.pm does not work:
```
# Delete local cache
if ( $class->tsv->{refLocalStorage}
and $class->tsv->{refLocalStorage}->get($id) )
{
$class->tsv->{refLocalStorage}->remove($id);
}
```
### Possible fixes
* Removing CDA cookie is not enough because you can have multiple CDA sessions
* Fixing the removal of local cache kinda-works, but not a perfect solution either. Because you can have multiple handler servers.2.0.10Maxime BessonMaxime Bessonhttps://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/issues/2379SameSite attribute for 1.92020-12-02T08:48:01ZMaxime BessonSameSite attribute for 1.9### Concerned version
Version: 1.9.21
### Summary
Some use cases are now broken when using 1.9 with Chromium-based browsers (which today means everything that is not firefox), see #2070.
Firefox will introduce the same change [event...### Concerned version
Version: 1.9.21
### Summary
Some use cases are now broken when using 1.9 with Chromium-based browsers (which today means everything that is not firefox), see #2070.
Firefox will introduce the same change [eventually](https://hacks.mozilla.org/2020/08/changes-to-samesite-cookie-behavior/)
### Possible fixes
Adding SameSite to cookies is not as simple as it seems.
1.9 uses CGI::Cookie, and old versions of CGI::Cookies do not handle SameSite at all. Event recent versions of CGI::Cookie do not handle SameSite=None (only Lax and Strict)
I have a prototype patch that hacks around this limitation
Maybe this change deserves a 1.9.22 release @cleoud ?1.9.22Maxime BessonMaxime Besson