search

Shopify / koa-shopify-auth

DEPRECATED Middleware to authenticate a Koa application with Shopify
MIT License
80 stars 63 forks source link

Handling generated records sessions #73

Closed devopsangel closed 3 years ago

devopsangel commented 3 years ago

Issue summary

Every time when I load app new sessions get generated.

Expected behavior

Generated sessions need to be deleted either on deleteCallback or sort of periodically job clean.

Actual behavior

image

I am wondering how other folks handling this.

kato-takaomi-ams commented 3 years ago

I want to know why validateAuthCallback saves both uuid and online sessions.

devopsangel commented 3 years ago

@kato-takaomi-ams fyi https://github.com/Shopify/koa-shopify-auth/issues/64#issuecomment-797587199

kato-takaomi-ams commented 3 years ago

@devopsangel Thank you for the information. I think there are 3 types of id in your session storage.

No. type of session ID format beginAuth validateAuthCallback
1 online temporary {uuidv4} generate update
2 online {shop}_{associated_user.id} --- generate if IS_EMBEDDED_APP
3 offline offline_{shop} generate update

I want to know who uses the No.1-session and how after validateAuthCallback. Knowing this, I will understand the need to delete the No.1-session for this issue.

devopsangel commented 3 years ago

@kato-takaomi-ams yeah I want to know that too :) but per @paulomarg it is unavoidable.

The reason behind it being called twice is that it stores the session once when OAuth begins, mostly so it can store the state - we check that when completing the OAuth process to make sure the request actually matches the OAuth process that we start, for extra security.

that will be required during the initial oath dance. Most likely we will need to do some cleanup when on scheduled process or during the expires validation.

I do remove for now during expires validation. I am not sure if it is right way to do.

paulomarg commented 3 years ago

Hey folks! The first session in @kato-takaomi-ams's comment is the OAuth session. In the case of embedded apps, we first need a cookie-based session on the browser top level to store the information we need when coming back from OAuth. With that information, we can set up the session that will be used by the App Bridge session token.

We could make sure those sessions are deleted when we complete the OAuth process, so you won't be left with those hanging sessions, at least for embedded apps - unfortunately we need a random id for non-embedded apps which will continue using the cookie-based session.

devopsangel commented 3 years ago

thanks @paulomarg! I am going to close this issue.