Q: Problem with SSO login from /en/home vs. /home

[zipwiz]

After successful deployment with "standard" language we have issues with explicitly selected non-standard language:

When working with default language, URLs look like https://my.server.org/myContent . Click on "Login" then calls /c/portal/login and everything is fine.

After switching to EN (it is a German portal), URLs look like https://my.server.org/en/myContent. Click on "Login" then calls /en/c/portal/login -- and this does not trigger OIDC SSO login but Liferay default login.

What are we missing? Is that because of the filter URL path snippet /c/portal/login in liferay-hook.xml? Or is it possible that our proxy is not configured well? Or something else?

Any usefull hint is appreciated.

[gvanderploeg]

Hi,

Thuis could well be caused by the filter order... sso filter before language selection filter. But as far as I can remember I copied the idea from the built in CAS filter, so that should suffer from the same error I suppose.

I will look into it further next week. But maybe the above already gives you a clue.

Geert

Op 2 feb. 2018 2:18 p.m. schreef "Christian Gosch" <notifications@github.com

:

After successful deployment with "standard" language we have issues with explicitly selected non-standard language:

When working with default language, URLs look like https://my.server.org/ myContent . Click on "Login" then calls /c/portal/login and everything is fine.

After switching to EN (it is a German portal), URLs look like https://my.server.org/en/myContent. Click on "Login" then calls /en/c/portal/login -- and this does not trigger OIDC SSO login but Liferay default login.

What are we missing? Is that because of the filter URL path snippet /c/portal/login in liferay-hook.xml? Or is it possible that our proxy is not configured well? Or something else?

Any usefull hint is appreciated.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/finalist/liferay-oidc-plugin/issues/18, or mute the thread https://github.com/notifications/unsubscribe-auth/ABG69scH1SYRiIyASPLA7rVRYVvEtJLFks5tQws4gaJpZM4R3K13 .

-- http://www.finalist.nl

[zipwiz]

On the site in question, CAS was used before and had similar problems which took a long time (ago) to fix.

How then can I determine and control the filter order in this case?

[zipwiz]

Idea: Since URL patterns for servlet filters are quite restricted (e. g. see https://stackoverflow.com/questions/8570805/can-we-use-regular-expressions-in-web-xml-url-patterns ), it should be possible to simply catch all URLs by declaration and then handle only interesting URLs by implementation. In fact the current implementation already works this way (but the liferay-hook.xml selects more restrictively).

Of cause the disadvantage would be that every request is piped through the filter, although only login (and maybe logout) URLs should. But this may be acceptable in case of no alternative.

I will check if this at least works. Then you may (depending on further investigation results) decide whether this should become part of the project or not.

[zipwiz]

Works.

Next issue: Is it possible to guess the current "content locale" on the Liferay side and forward it to OIDC OP using URL parameter ui_locales (as described in http://openid.net/specs/openid-connect-core-1_0.html#AuthRequest ) ? If the request Locale is not set appropriately it is not that simple to guess it from the available request data like URI, URL, contextPath, servletPath and pathInfo because Liferay always treats the first path element as servletPath, regardless of its semantics...

[gvanderploeg]

Hi, Although I like that you fixed the i18n-issue, I'm not sure yet what to think of the fix itself... I still hope that the language URL-prefix (/en, /nl etc) would be removed by Liferay after it has done its job, otherwise all filters should have the same issue... this still annoys me :-)

About the ui_locales: I created this as a separate issue, #21. Let's discuss it there.

[zipwiz]

Btw. I do not like this way of implementation either, but so far I did not find another way to

• catch all relevant requests to process them in the code, and to
• retrieve the current language (or locale) for sending it forward to the OP.

Improvements are really welcome!