> Do you use a generator to build your sdk? i don't, and i don't see anything along those lines in the official ones. i'm just referring to the Node SDK. i've spent about a day reading through the code, and now i feel like i can port it relatively quickly-- hoping just a day or two with integration testing.

i'm specifically looking at using this in ASP.NET Core, and Microsoft already provides a modular authentication & authorization framework. it's looking fairly straightforward-- i simply need to implement a few, required abstractions. it looks like the bulk of my work is reverse engineering things like the above so that i can map it into the existing framework.

@seniorquico sorry, the question what's for @rp Ok, if it's a really hand made sdk, I understand and yes, it's what I'm looking also for Actix-Web (framework in Rust) but for the MVP, I can continue with fastapi. If I remember, Entity framework and another in C# are working well so yes, maybe it's not very hard to do all abstractions but it looks like crazy to don't respect the RFC, finally with the information from @rp , I understand why they're not respecting it.

@sycured for fastapi, it should be a few weeks.. we are building a generic python SDK and will add a fastapi wrapper to it.

@rp wow, you're working hard, thank you Will it be possible to use it with template in case of not using an spa? I'll have near 5-10 pages where spa will be very slow for browser side but I'll look to build it with wasm and library written in Rust

I’m not sure what you mean by template - do you mean server side rendering?

Yes

The old way to build website

Yea. We can work with that, as long as your API domain is the same (or subdomain) of your website domain

I’ll have a look at templates for fastapi soon. But I’m not too familiar with it.

It's the same with flask

I could describe the general approach we have for SSR + sessions and you could implement that using our SDKs (once they are available for python)

In fact, we may be writing a blog post about this very soon. So I’ll post that here once we have it

Ok thanks, I can wait the need sdk

Hi @User > I want to have a group of new users who can only log in to the new app (they should not be able to log in to the current app). > How are you going to prevent these users from logging into the previous app? By detecting their email used and preventing them from signing up / logging in? I was thinking about assigning roles to users, to check which app they can access. I do not use signup at all, users are created manually, so I can add roles easily. On login, the backend would need to know from which frontend app the log-in call comes (send some custom field along with the credentials from frontend?). Basing on it and the user role I could decide whether the user can log in and create a session (with a role assigned) or return some error.

@Orszi understood. Everything you mentioned should be possible with our new update (will be released in a few days). Post that, we can discuss how you can go about implementing the above (if the docs are not clear enough).

@rp thank you very much for your quick answer. I will check the new update and get back to you if have any question.

Just for an example of what I call "old way using templates", it's a basic but working example: https://eugeneyan.com/writing/how-to-set-up-html-app-with-fastapi-jinja-forms-templates/

@User , at a high level, what you want to do is this: - Let's say your api domain and website domain is example.com. Your api path is something like /api/* - The session cookies will be attached to example.com in this case. - On each request to api from the frontend, the browser will attach the session cookies for session verification. In case the access token is expired, then the api will return 401, and the frontend (our SDK) will automatically refresh the session and re-call the API again. So far so good. - Now in case of templates, the user would navigate to example.com/somePage on their browser. - Like always, the browser will send the access token (not refresh token) to your webserver. - If the access token is valid, all will be good and the webserver can fetch the user's info and fill it in the template to return the html. - Now in case the access token has expired, instead of sending a 401 to the frontend, your backend will need to send some JS / HTML that will manually refresh the session (see https://supertokens.io/docs/website/usage/server-side-rendering). - If manually refreshing is successful, you can reload the page and this time the access token will be valid and the user can see the content. Else, you can take the user to the login screen. ------------ From the user's point of view, this looks like: visit example.com/somePage -> see some loading screen (refresh happening) -> see content

I noticed that 1Password (https://1password.com/) doesn't work on Supertokens sign up screen, could you look into this? I wasn't able to figure out any details on why this was happening, hence the reason for lack of information regarding this issue.

@User you may want to disable use of shadow dom for enable password managers to work: https://supertokens.io/docs/thirdpartyemailpassword/common-customizations/styling/shadow-dom

But be sure to check the UI once to make sure no CSS clashes.

context: I asked about Golang ETAs back on May 28 > rp — 05/28/2021 > Nice. We're actively working on it at the moment and hoping to launch with full functionality (including login etc) in a month. Let me revert about updating it to just work with sessions and the latest core > So session support for golang should be out in 2-3 weeks. For the rest of the recipes, those should be supported in another 2-3 weeks post session recipe being released. how're we tracking?

@User , we have finished 60% of the SDK so far - session and emailverification recipe + a lot of the routing and error handling logic is done. We are working on the emailpassword recipe right now. You can see the SDK here: https://github.com/supertokens/supertokens-golang/tree/0.0 Also, please feel free to contribute to it (porting code from node SDK).

Hi, what algorithm is used to store passwords in supertokens?

bcrypt. You can see the code here: https://github.com/supertokens/supertokens-core/blob/b0823ad85db003e48bd6e62be99b257cfdd519da/src/main/java/io/supertokens/emailpassword/UpdatableBCrypt.java#L25

And if you would like to use another algo, you can fork the repo, and change it as you like 🙂

great, thanks a ton! one more Q, where is the salt saved?