Session persistence / cookies

Kevin B Posted in Component Development 3 years ago

Have a strange issue with my WebChat component which makes me think it could be a session persistence thing?

If I log on to chrome on my PC with the admin account, and then logon to the mobile app with a different account, I get a "too many redirects" error.

If I clear the browser cache, visit the website on the mobile browser, and log back in... The mobile app then seems to work perfectly.

You can see this on demo site

It feels as though the PWA is not logged on, so is being redirected to login, but Google's cached session says I am logged on so redirects it back to the WebChat creating an infinite loop.

Does this sound feasible?

Is there a way to tie the cookies/session to the host (my mobile and pc will present as the same source IP through the same router) or is it more likely an issue with my component?

Replies
gb Kevin B Replied 3 years ago

I think that's fair. I had initially intended for it to be completely standalone relying on the API. But I think it's evolved as my understanding of OSSN has improved. I think it will end up not using the API at all, and just being a component of ossn.

Since the earlier post, i've stripped back the page registration stuff. It now registers it only once. It only displays the content if you are logged in.

Much simpler and makes sense.

However, I have now discovered the root cause of the issue... and it is cookie persistence as I first suspected.

When you first visit a page thats not logged on to, Private Network sets a cookied named "ossnrestrictedurl_visited" with a 2 minute lifetime.

When you successfully logon, this cookie is not deleted.

All the redirect loops I was seeing were triggered by this cookie.

I made one single change to the Private Network component - changed the lifetime of the cookie from 2 minutes to 5 seconds.

Then when logging in, and watching the network requests in Chrome, I could see the redirect occurring for a couple of seconds before the cookie expires, and then the page loads successfully. With the 2 minutes it was just contantly redirecting until the browser times out and stops attempting to load the page.

I have logged off and on a number of times now, with and without the cookie lifetime amended, and can reproduce the issue each time.

German Michael Zülsdorff Replied 3 years ago

Thought? Indeed! :)
Honestly, I think your Webchat is drifting to a wrong direction, causing all these side-effects and workarounds.
In the beginning it looked like you were going to develop a real standalone application using Ossn's API, and then - and to my opinion only then - making it a separate PWA makes sense.

But actually it evolved to a mixture - half standalone at first sight from the PWA's point of view, but in the end still connected to the main site, which - not to forget - may be a PWA, too! And this main-PWA / sub-PWA is not only confusing but will cause all kind of caching issues on mobile devices.

Thus, I can only recommend to either continue with a complete standalone application or make it just a 'normal' component's driven subpage of the main site and use the already existing mainsite manifest.

gb Kevin B Replied 3 years ago

Little bit of further investigation turns out it was my code... but I know why. Posting here as it may be useful to somebody else in future.

So in my ossn_com.php, when initialising the component I check whether the user is logged in.

If they are logged in, I register the page "webchat" and they are then presented with the WebChat screen.

If they are NOT logged in, I register the page "webchat", BUT with a redirect URL to login.

Without this step, when people tried visiting "/webchat" directly (which is what the PWA mobile app will need to do), instead of simply redirecting to login, it was presenting a 404 page not found error instead. This is understandable because the webchat page at this point does not exist.

However, this scenario created an infinite redirection when the cookie/session expires. Here's why:

1) Client visits "/webchat"
2) User is not logged on, so page "webchat" is registered with a redirect to login.
3) Browser visits "/webchat" and is correctly redirected to "/login"
4) Client provides credentials and is then redirected to "/webchat"
5) User is now logged on, so page "webchat" is registered providing a view of the webchat page.

HOWEVER - Step 5 does not work correctly because "/webchat" is aready registered, and is pointing to the redirection page!

The fix?

Just before registering webchat in the loggedin section, simply add a "ossnunregister_page ("webchat");'

And that resolves the issue.

I should probably wrap an error around that to prevent it from causing an error when the page is not already registered... but haven't seen that occur.

Thoughts?

gb Kevin B Replied 3 years ago

Oooh awesome!!! Thanks 👍

German Michael Zülsdorff Replied 3 years ago

Okay,
PrivateNetwork 5.3 comes with an appropriate hook now.
Enjoy. :)

German Michael Zülsdorff Replied 3 years ago

Right. And just a suggestion as long as there's no easy extendable PrivateNetwork available.

gb Kevin B Replied 3 years ago

Doesn't that mean the component must be disabled? That's a good thought, but I really need Private Network to work too. So ideally I'd be able to extend the array (I've seen this done in other components, just can't remember where) or manually update the file (worst option as i'd rather not be manually updating other components). I think the notice I added should cover it until I figure out the next step?

German Michael Zülsdorff Replied 3 years ago

A note is fine,
more secure will be adding a pre-requiste to the xml like

<requires>
    <type>ossn_component</type>
    <name>PrivateNetwork</name>
    <comparator>disabled</comparator>
</requires>  
Indonesian Arsalan Shah Replied 3 years ago

Good to hear that. Maybe you can add notice that this doesn't work with private network.
I agree, private network component needs some kind of hook that allow other components to extend it. I'll be looking forward to modify it.

gb Kevin B Replied 3 years ago

Fixed it!!!

I noticed in the cUrl a statement "restricted URL" which pointed me back to Private Network.

I'd not added webchat, chat_api and API to the exclusion array.

On the browser it worked fine, but for some reason the PWA app was affected by this. I added the exclusions et voila! The webchat is now working fine on the demo site :)

Is it possible to extend that array from the webchat component init?