Lithium SSO zlib deflate

Out of interest, what is the issue with compressing the token?

I imagine the reason for the compression is that the SSO token can be very long if specifying a lot of user settings.

The web server that we want to use to integrate from does not allow the use of compresion. So we just do not have access to that function.

We only plan on sending over 5 fields, First Name, Last Name, SSO ID, Email, and Country. 

If you're using one of the standard Lithium SSO libraries, I would have thought it would handle the compression/encryption for you. Assuming you're trying to create an SSO cookie, you're going to be limited by what is supported by Lithium. DougS or JeffY can probably tell you if there is any support for uncompressed SSO tokens.

If you only need the SSO token for one user (e.g. an external application to use the API), you could use user/password authentication to get a token via the API. You'll need to set up a non-SSO user to do this though.

Hi Nathan,

I tested with our dev site and it worked witout compression so I wanted to make sure it would work on production and not randomly break. I am not using a standard library because the system I am SSO'ing from does not support PHP,Java, or .Net.

DougS and @JeffY any ideas?

There is no way currently in any of our SSO clients (Java, .Net, PHP) to turn off compression, however I looked at the code and it looks like we might allow it to come over un-compressed on the community side, however I couldn't say for certain without trying it out.

-Doug

Hi DougS,

That is great! I tested on our dev site and it worked. If it works in production then would I be able to use the integration without compression ? 

Will it be supported in the future ?

Thanks,

Matthew

DougS 

I deployed to production without compression and it has been working for a week.

Thanks Doug !!

Great to hear!  I added that automated test, which will be run continuously to make sure the functionality doesn't break in future releases.

-Doug