search

Acosix / alfresco-keycloak

Alfresco addon to provide Keycloak-related extensions / customisations for Repository and Share
Apache License 2.0
36 stars 20 forks source link

Problem with redirecting to requested URL #22

Closed howkymike closed 3 years ago

howkymike commented 3 years ago

The "Login" button works fine, but after clicking "Single Sign On" button, the redirect_uri param (taken from form's hidden input element) is always "https://example.com/share/page/" instead of the requested URL (i.e. https://example.com/share/page/site/example/document-details?nodeRef=workspace://SpacesStore/abcdef-9754-42f7-20dc-8db73dc5c158). I checked prepareLoginFormEnhancement(context, req, res) method from KeycloakAuthenticationFilter.java and I noticed that 1) captureFacade.getRequest().getURI(), 2) redirect_uri param from redirects.get(0) and 3) req.getRequestURL() - they always return "https://example.com/share/page?" instead of requested URL. The problem disappears when I remove external-auth line from "alfresco" endpoint in the share-config-custom.xml (but then obviously Keycloak does not work). Does anyone also have the same problem or did I just messed up with the configuration? As a workaround, I temporarily modified login.get.js to use successUrl (taken from context.properties.alfRedirectUrl) But still, I cannot force it to add params to the url, which is problematic with the Document library links (i.e. filter param in the https://example.com/share/page/repository#filter=path%7C%2FData%2520dictionary%2FQuick%2520Share%2520Link%2520Expiry%2520Actions%2520Space%7C&page=1)

howkymike commented 3 years ago

There is the same result while setting <force-keycloak-sso>true</force-keycloak-sso> - redirection works except Document Library browsing (#filter=path%7C%2FXXXX parameter is missing)

AFaust commented 3 years ago

Since the redirect URL is determined on the server, the client-only URL #filter=path%7C%2FXXXX cannot be included in the redirect URL. Even with default Share, if you have navigated somewhere in the document library, are inactive for a while and then have to re-login via its login form, you are not redirected back to the same folder you were in before - you are instead directed again to the root of the document library.

As for the regular URLs not being used as redirect URIs, I have not had time to check myself yet. Hopefully I will have during the weekend when working on my TTL preparations.

howkymike commented 3 years ago

Do you mean #filter can not be included in the redirect_uri URL param? That would be sad. Without Keycloak (default Share) I can open a link (which includes #filter param), sign in and I will be correctly relocated.

AFaust commented 3 years ago

The problem is that the # are never sent over the wire at all, so the server-side logic is unaware of them and cannot generate a redirect URL for it. In default Share, during redirect from the link you opened to the login page, your browser actually preserves the #-parameter, but they are not sent to the backend. A client-side JavaScript component (login.js) then adds the #-parameter back to the successUrl hidden form field. I must admit, I have not tried that for the redirect URL for Keycloak, mostly because whenever there is a mismatch between the URL that is used by the client as the redirect URL and the one used by the server-side component when validating / exchanging an authentication code with Keycloak, the handshake typically fails. But maybe Keycloak can ignore mismatches of the #-params, which the server side cannot send (it does not know of them) in the validation request.

howkymike commented 3 years ago

Oh, that finally makes sense. Thank you very much. I tried to play with Keycloak but as you said, the handshake was failing (or I did sth wrong).