AW: IDP3/4 -> read (&write) custom session cookie for authentication

[Käfer Thomas]

Ah sorry, that one was easy, should have searched the release notes before asking the list 😉
replaced
idp.csrf.enabled = true
with
idp.csrf.enabled = false
in conf/idp.properties

sorry and thanks for the help! 🙂
________________________________
Von: Käfer Thomas <thomas.kaefer at fh-campuswien.ac.at>
Gesendet: Dienstag, 4. April 2023 17:48
An: Shib Users <users at shibboleth.net>
Betreff: AW: IDP3/4 -> read (&write) custom session cookie for authentication

Thank you for the explanation and the hint to look at the Release Notes! Found them here: https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631499/ReleaseNotes#4.3.1-(March-30,-2023) and they referenced this more detailed guide: https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/3139993601/Moving+to+Suppliers+for+accessing+HttpServlet+Objects

With this information I managed to repair my SSO AuthFunction - but I've got another problem that prevents my IDP 4.3.1 from working as hoped:

WARN [net.shibboleth.idp.ui.csrf.impl.CSRFTokenFlowExecutionListener:183] - CSRF token is required but was not found in the request; for view-state 'DisplayUsernamePasswordPage' and event 'proceed'.
WARN [org.opensaml.profile.action.impl.LogEvent:101] - A non-proceed event occurred while processing the request: InvalidCSRFToken
ERROR [org.apache.velocity.loader:355] - ResourceManager: unable to find resource 'status.vm' in any resource loader.

The webpage displays "CSRF-Token-Verifizierung fehlgeschlagen" - Can you give me any pointers how I could solve this problem?

Thank you!
Kind regards,
Thomas Käfer

________________________________
Von: Cantor, Scott <cantor.2 at osu.edu>
Gesendet: Dienstag, 4. April 2023 14:20
An: Shib Users <users at shibboleth.net>
Cc: Käfer Thomas <thomas.kaefer at fh-campuswien.ac.at>
Betreff: Re: IDP3/4 -> read (&write) custom session cookie for authentication

The type of that bean is different in 4.3.

Look at the release notes for details on the conversioon to the supplier bean to access the servlet request, and in general avoid auto-wiring and anotations. They are not suited to production use cases, those are toys that are focused on Spring as a rapid deployment tool. We use them, but we also understand their (huge) limitations.

Our contract is through class types and bean names, but never the combination of the two. That will not allow for safe upgrades.

-- Scott



Informationen zum Datenschutz: www.fh-campuswien.ac.at/datenschutzerklaerung
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20230404/b9839bcf/attachment.htm>