Hey @User we don’t have an android SDK yet.

Can I use this method to authenticate via an android app? https://supertokens.com/docs/android/1.0.X/httpurlconnection/init

That SDK is outdated and won’t work with the latest version of the core and backend SDKs

ok thats great information, thanks

If you’d like to contribute to it to update it, that would be much appreciated

With Auth0 you can define rules. I am not so sure how they work exactly, but I guess "onAcquiring a Token" you can make a callback. So I could use that trigger to authenticate on a another service I would like to use. So if I am right and if that is possible with SuperTokens, I would not need to implement a session management and can let that handle SuperTokens authenticating the User on the other service I am using.

Yes. You don't need to implement session management yourself. We do that for you. We also issue JWTs which you can send off to other services (if they expect a JWT). Our version of auth0 rules is called "override". It's like inheritance in which you create a child class of the parent class (which is our implementation), and override the default implementation with your custom logic. You can learn more about it in the advanced customisation section for the recipe you choose.

I was looking for rules. Now I found "override". So It means that the token is send from my service to any other service?

The token is sent from the backend to your frontedn

Something small we're probably missing, from the pseudocode, it seems that when a session is initially created, a refresh_token is returned, but since this the hash of this is stored in the session at this point, isn't it a parent_refresh_token and therefore unable to extend the session when refresh endpoint is called?

It’s not considered a parent refresh token until it has already been used to create a new refresh token.

At this point, it can either be used to generate more child refresh tokens, or then if any one of its children is used (making it a “grandparent” token), it is revoked from the db and will then be unusable

Ah ok, that's how we expected it to work. We were confused because the pseudocode states that the double hashed refresh token is stored in the session upon creation, and from the

refresh session

logic, it appears that the token hash stored in the session defines the parent refresh token

The double hash is stored on session creation. But that still implies what I said in my last comment.

Hey @User if you got around to implementing those Angular interceptors for Supertokens, I'd love to get my hand on 'em. Would much rather use Angular's http client rather than switch-over to Axios or fetch. If you could bootstrap me with those interceptors that'd be nutty. Cheers.

@User is this a blocker for you?

Yes it was. Was able to make my own interceptor though, not too complicated. It triggers on a 401 if statement and invokes that refresh function supertokens-website has, then retries the request. If still error after that, just throws.

Makes sense!

If you have time and can make a PR for it, that would be great!

Or just an issue describing your code.

Yup no worries, if I get around to it will do then. Cheers. Also, enjoy y’all’s weekends lads 😄

You too!

I have a question regarding using supertokens node in express. If I throw an error manually in one of my routes, after errorHandler() middleware, will the error be forwarded using next if it's not a supertokens error?

> If I throw an error manually in one of my routes, after errorHandler() middleware The supertokens errorHandler middleware should be declared after all your routes. So im not sure what you mean by this statement.

Let me explain

I have a global error handler for my express app

This is how I'm trying to do it, but it errors out because I'm actually getting next in err

So error is getting req context I think

If I move app.use(errorHandler()); below mine, it will never run, I am little lost on how to handle this situation