URL parameters lost after LoginController

65 views
Skip to first unread message

Jackson, Allan

unread,
Aug 6, 2019, 12:14:36 PM8/6/19
to uporta...@apereo.org

We just upgraded to uPortal 5, and I’m seeing an issue when deep linking to a portlet from an external system. If the user is already logged into the portal, the link works fine, but if they have to go through the portal’s LoginController first, the request parameters are getting stripped off.

 

I recorded the list of URL redirects that the browser goes through (with some fake portlet names and data):

 

  1. http://localhost:8080/uPortal/p/PortletName?action=/DisplayStudent&studentId=1234567&anotherOption=true

 

  1. https://CasServerUrl/cas/login?service=http://localhost:8080/uPortal/Login%3FrefUrl%3D%2FuPortal%2Fp%2FPortletName%253Faction%253D%252FDisplayStudent%2526studentId%253D1234567%2526anotherOption%253Dtrue

 

  1. http://localhost:8080/uPortal/Login?refUrl=/uPortal/p/PortletName%3Faction%3D%2FDisplayStudent%26studentId%3D1234567%26anotherOption%3Dtrue&ticket=CasTicketHere

 

  1. http://localhost:8080/uPortal/Login?refUrl=/uPortal/p/PortletName?action=/DisplayStudent&studentId=1234567&anotherOption=true

 

  1. http://localhost:8080/uPortal/p/PortletName?action=/DisplayStudent

 

The step that is actually hitting the portal’s LoginController class is #4 (step 3 never makes it clear to the controller). At that point, it tries to pull out the refUrl parameter, but the URL has already been fully decoded, so the refUrl only goes up until the very first ampersand character instead of including all the parameters that it should contain.

 

 

After writing up the start of this email, I tried downgrading the cas-client jar to v 3.2.2 (from 3.5.1), and that actually fixed the problem. Using that version of the cas client, I’m seeing these URLs:

  1. same
  2. same
  3. same
  4. NONE
  5. http://localhost:8080/uPortal/p/PortletName?action=/DisplayStudent&studentEmplId=1234567&anotherOption=true

 

The crucial difference here is that it only tries to hit the LoginController one time (and it’s using the correct url encoding at that point).

 

Does anyone have any ideas about ways to resolve this? That jar file is being pulled in by uPortal core, so it’s not easy to downgrade it with our default build options. At this point I’m still not sure if it’s a bug in the CAS code, uPortal code, or some sort of version mismatch with the standalone CAS we’re running.

 

Thanks,

Allan

Jackson, Allan

unread,
Aug 6, 2019, 2:51:49 PM8/6/19
to uporta...@apereo.org

After poking around in the CAS source code, I found the encodeServiceUrl parameter. This setting defaults to true, but it was disabled for uPortal core with an unrelated commit last year. Does anyone know more about why this was changed? If I set the value back to true, it fixes the issues I’m seeing.

 

https://github.com/Jasig/uPortal/commit/579913b5d45f03bca167813b090b61cec323f0e9

 

Allan

--
You received this message because you are subscribed to the Google Groups "uPortal Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to uportal-user...@apereo.org.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/uportal-user/B56832BF-6751-4E20-A559-8181E8D10F11%40ku.edu.

Jonathan M. Tran

unread,
Aug 6, 2019, 3:30:01 PM8/6/19
to uporta...@apereo.org

encodeServiceUrl = false was added as part of a fix for UP-5000. I unfortunately didn't document what the URLs looked like before and after the encodeServiceUrl change to recall what exactly it was that made CAS unhappy in the past ... It looks like I was chasing down two things at that time
Setting encodeServiceUrl to true, things appear redirect and serviceValidate as it should. I imagine that it should be changed.

Luckily, this bean can be overriden in overridesContext.xml until its updated in upstream.

- Jonathan

Jackson, Allan

unread,
Aug 6, 2019, 3:34:47 PM8/6/19
to Jonathan M. Tran, uporta...@apereo.org

Ah, thanks for the context! I did notice some differences in the way the cas-client was behaving between versions 3.3, 3.4, and 3.5 so it’s possible that the encodeServiceUrl=false change was needed at that time but no longer is.

Julien Gribonvald

unread,
Aug 14, 2019, 4:45:46 PM8/14/19
to uPortal Community, j...@cpp.edu, allanj...@ku.edu
Hi,
sorry to be late in this topic.

Just one thing, did you make all test with the embedded CAS ?
This params seems to depends on the CAS version also, for older version you should keep this param to false. As example with my CAS the encodeServiceUrl set to true doesn't permit to validate correctly the uPortal service.

Also on one other post l told that this parameter should depends on user customization, and in best case it should be compatible with the CAS embedded.

-
Julien

To unsubscribe from this group and stop receiving emails from it, send an email to uporta...@apereo.org.

--
You received this message because you are subscribed to the Google Groups "uPortal Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to uporta...@apereo.org.

--
You received this message because you are subscribed to the Google Groups "uPortal Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to uporta...@apereo.org.

Jonathan M. Tran

unread,
Aug 20, 2019, 11:38:16 AM8/20/19
to uporta...@apereo.org

I wrote up a pull request to make this a property such that it can be easily toggled:
https://github.com/Jasig/uPortal/pull/1855

If/when this gets merged, I'll make a similar PR in uPortal-start with encodeServiceUrl set to false such that it works with the bundled CAS server.

The blurb/documentation surrounding this property could use additional eyes, so please comment on the PR

- Jonathan
To unsubscribe from this group and stop receiving emails from it, send an email to uportal-user...@apereo.org.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/uportal-user/46ee2c82-d5c6-4752-8bf5-a7d1c59797a6%40apereo.org.
Reply all
Reply to author
Forward
0 new messages