DEV Community

sfrunza13
sfrunza13

Posted on

Who stole the cookies from the...

Last week in Starchart

In the last week I was a part of a few extra meetings alongside the regular team stand ups for our open source project Starchart, a meeting at the start of the week to discuss the new SLO implementation with David where we arrived at a neater solution for the SLO cookie and made it strict and restricted it to the logout route. At the same time we made the session cookie strict, I had forgotten what I had seen when looking at telescope's cookies. We also made some UI changes to the logout prompt making a less prominent button that would initiate SLO and a more vibrant red one that would just redirect you to sign in having only invalidated the session cookie with the starchart website. In any case, I was able to land the new SLO flow at the beginning of this week after some discussion and then demonstrated in a consequent mid-week meeting with the team PR #366.

I also did a few reviews, although here I will only mention one of them since I felt I added a bit more to this PR than others PR #414.

Cookie problems

Here we have the impromptu bug that refreshed my memory on one of the problems with cookies when doing SSO. When my SLO change was incorporated into staging it seemingly broke something when signing in, making it so that a user would have to sign in twice to be authenticated to Starchart. My first instinct was to check the networking tab and to take a look at the cookies because I remembered we set the session cookie to strict and lo and behold the session cookie was being rejected since the browser claimed it set as a result of a cross-site request. The browser was of course correct, the session cookie is set on our login callback as a result of a request from our IDP which is a different origin and indeed cross-site, since we set the session cookie to be strict it would not be set by any cross-site requests at all. The simple solution here was to set the cookie to lax instead of strict and allow it to be set as a result of a cross-site request and this seems to be the general consensus when it comes to SSO seeing as session cookies are very often set as a result of a callback from an entity separate from our website. We did however keep the SLO cookie as strict since it really only exists and needs to be used within the one logout route that I have written within our own application. In any case here is the one word PR that fixed our double login issue PR #427

Next Steps

Next I need to take a look at allowing admins to impersonate users in Starchart which I should do by adding information to the session, an "effective user" field that will come empty for admins so that they can set it to who they would want to impersonate and that would come forcibly filled with a regular user's own username so they can not in fact impersonate anyone else.

Top comments (0)