* Update render.js
# Improved handling of mustache expressions and v-pre attribute assignment
## Changes Made:
- Ensured that the parent tag of such text nodes is explicitly set to a `<p>` tag with the `v-pre` attribute.
- Added debug messages for better understanding of the script execution flow [THIS SHOULD REMOVED WHEN PUSHING TO PRODUCTION].
## Why it Works:
- When a mustache expression is found, the script either wraps it in a new `<p>` tag with the `v-pre` attribute or adds the `v-pre` attribute to the existing parent `<p>` tag.
- This approach ensures that the template code is not removed but encapsulated within `<p>` tags with the `v-pre` attribute, as required.
## Test Cases Passed:
1. `<xyz>{{ constructor.constructor('alert(1)')() }}</xyz>`
2. `<xyz>{{ constructor.constructor('alert(1)')() }}</xyz>`
3. `<p><xyz>{{ constructor.constructor('alert(1)')() }}</p>`
4. `<p><xyz>{{ constructor.constructor('alert(1)')() }}</xyz></p>`
5. `<p><xyz>{{constructor.constructor('alert("Test Case 8")')()}}<xyz>{{constructor.constructor('alert("Test Case 9")')()}}</xyz></p>`
This commit enhances the robustness and reliability of handling mustache expressions and ensures proper assignment of the `v-pre` attribute, to ensure that there is no room for the weaponization of the template code later in the rendering process.
* fix: move template expressions after dom-purify + handle text nodes without parent
---------
Co-authored-by: NGPixel <github@ngpixel.com>
* feat: added implementation for group mapping in SAML strategies
---------
Co-authored-by: Abderraouf El Gasser <abderraouf.elgasser@iktos.com>
Co-authored-by: Nicolas Giard <github@ngpixel.com>
HTTPS redirection rebuilds the full URL using req.originalUrl, which
includes query parameters (see
https://expressjs.com/en/api.html#req.originalUrl). Prior to this patch,
appending the stringified query params to req.originalUrl resulted in
duplicate parameters, e.g.
wiki.js/callback?session=123&code=abc?session=123&code=abc
which caused errors when being redirected from an insecure (http://)
callback URL to a secure version when using OIDC (e.g. with keycloak).
This issue is probably rare, but in cases where HTTPS redirection is
enabled and a user tries to hit an insecure URL with query parameters,
it could cause problems.