Verifying a session from a different backend

After fixing the cors issue, now the session doesnt last for long (maybe 30 minutes) on the second front-end. Its as if the access token doesnt refresh automatically. Anything special I need to do?

Hey @rp does Supertokens support Saml using BoxyHq with passwordless recipe?

Also, any estimates on SSO?

SAML with passwordless

SSO (us being an OAuth provider) should be available in 2-3 months

Hey guys, I am using

supertokens-python==0.8.2

with

Django==4.0.6

and resend code is not working for passwordless. Is it a known issue for python SDK version I am using? It is a POST request from frontend to the URL

signinup/code/resend

with

preAuthSessionId

and

deviceId

payload. The response says

"status": "OK"

with 200 status, and the code is not being delivered. I cannot see any logs on the backend that indicate code resend attempt.

SSO us being an OAuth provider should be

hey, we're trying to add apple as a third party provider (since apple don't allow social login if you don't have apple as option) when we add apple as provider we get the famous

[object Object]

error, can't figure out why

I want to make that users logged on the main domain to be logged in on the subdomains as well with the same account and how do I install supertokens on there?

Also I'm using Hostinger

can we have non-minified version of web-js sdk in the bundle on jsdeliver, it will be easier to debug. currently it is minified

No minified version of web js

Hey there, is there a way to let supertokens use int / bigint instead of uuid as the primary key for the email_passwords table (and probably all other)? Like

user_id

would be 1 instead of "uq814uq-81412...."

👋🏼 Does super tokens support B2B easily similar to Auth0?

Hey all, Any idea how to implement SuperTokens with Chrome extensions? I am stuck trying to get it to work.

Does

supertokens-web

attempt a refresh on all 401s by default, or only when other response headers are also found (e.g.

rid

)? I saw my front-end looping requests when my API sent back an explicit 401 (not from

supertokens-node

, but from my own controller). It's fixed if I set the

sessionExpiredStatusCode

, but I thought there would be some other logic besides attempting a refresh on all 401s. Is this intended? I'm on

"supertokens-website": "^10.1.0",

and

"supertokens-node": "^9.2.3"

Infinite loop 401

Hi, I'm using a library for generating a typed api-client on my frontend (swagger-typescript-api), however it seems that the headers required by supertokens aren't set when using it. I don't understand why because the generated client uses fetch internally, which should be monkeypatched by supertokens (or so I understand) I also get an infinite loop of unauthorized requests. I am using the ThirdParty recipe. Do you know how I could fix this ?

Hey. I really like this library especially the passwordless recipe. One thing that doesn't quite make sense to me is that most auth solutions are implemented as a standalone API service which the frontend can directly talk to, but with ST you have to implement the endpoints using the backend sdk which is perfectly fine but that essentially renders the core useless. In theory you can just integrate all of the functionalities of the core directly into the backend sdk and completely get rid of an additional service.

Thoughts on adding an event on

supertokens-web

when the user's payload changes? Right now I'm getting around it by refreshing the session and doing what I need to do in that event handler, but it would be nice to have its own event action

Hello, what should I put in the websiteDomain appInfo on the init method of supertokens-node if I want localhost and the actual website to be able to use the same auth server?

Getting this error on calling

supertokensEmailPassword.resetPassword

emailpassword.js:1 Uncaught (in promise) Error: SuperTokensWindowHandler must be initialized before calling this method.
    at e.getReferenceOrThrow (emailpassword.js:1:105686)
    at t.getQueryParams (emailpassword.js:1:35831)
    at Object.getResetPasswordTokenFromURL (emailpassword.js:1:22726)
    at e.getResetPasswordTokenFromURL (emailpassword.js:1:14504)
    at resetPassword (reset-password?token=NjJjZTUxOTA2MWI2NmE5NmQ2NzYyNjlmOWQyOWE1OTVhZGJiNTYxNWU5NDk3YzU2ZDJlYjNhNTJkYmRkMzU4ZjYwMzM4YmJlOGZkODcyNTRhN2Y0ODQ1YmNkNDZjMmEw&rid=emailpassword:25:70)

Password reset error

Hello, I am using the frontend token payload to store user role and I am using this payload to check for access role in the backend, how safe is this approach? I manipulated the frontend token to change the role but the backend still sees my correct, true role instead of the manipulated role. So I assume this is safe?

By manipulation I mean, I base64 decoded the payload and changed it and encoded again and manually changed the cookie

Curious about plans for a Swift SDK and a VueJS SDK?

Hi quick and dumb question what routes does the backend have just so I can check if it's running or not (using GET request)? E.g. /api/auth/something

hey @rp can you add an integration example with go-zero https://github.com/zeromicro/go-zero