Is there a place to go to figure out what breaking changes need to be updated with each new update?

Or would I need to just read through the docs again and compare myself

Hello, currently following the setup for the backend. I have a TS project. https://supertokens.io/docs/session/quick-setup/backend#6-add-session-verification-to-your-api

how do I get the types for the

session

property under the

req

object? is that from

express-session

?

@User > Is there a place to go to figure out what breaking changes need to be updated with each new update? The CHANGELOG.md file in the repo on github should help you with this (as is the case with many projects). That being said, we will put in more effort into explicitly stating breaking changes somehow.. just not sure what is the best way yet.

@ZeferiniX to get the types, you can do:

js
import {SessionContainer} from "supertokens-node/recipe/session";

console.log("userId", (req.session as SessionContainer).getUserId()

oh there's a type, great, I think I'll augment the express request object with that instead 👌

how does one normally get to this page? https://supertokens.io/docs/nodejs/installation was trying to look how to possibly authenticate if I'm not using react, took me ages to find this, only arrived on it by accident 😓 that aside, if I understood correctly, there's no frontend login SDK currently for non-react apps so we'll have to make the calls (signup/signin/reset-password/verification) ourselves to the APIs but once the session has been created after a successful invoke from the backend SDK, we can then use the

supertokens-website

lib for session management, correct? now I'm trying to figure out how to add 3rd party custom provider (microsoft/office365 particularly)

according to docs https://supertokens.io/docs/thirdparty/common-customizations/sign-in-and-up/custom-providers#back-end-

it's under the

signInAndUpFeature

ugh, wrong, this doc link rather

thirdpartyemailpassword

https://supertokens.io/docs/thirdpartyemailpassword/common-customizations/signup-form/custom-providers

but that's non-existent in the latest version

not sure at this point if it's the docs that is wrong or the types on the lib, but something that needs fixing

in relation to that, would like some clarifications between the three 1.

EmailPassword

2.

ThirdParty

3.

ThirdPartyEmailPassword

the #3 shares the same init signature as #1, if #2 suggests it's both sign in + sign up in one go via

ThirdParty.signInUp()

, how does #3 behave with

ThirdPartyEmailPassword.signInUp()

? does it fire on both

signInFeature

and

signOutFeature

?

huh, think I figured it out

from

thirdpartyemailpassword

from

thirdparty

hey @User > how does one normally get to this page? https://supertokens.io/docs/nodejs/installation This is only meant for reference, and is not a tutorial guide. We had it more easily accessible earlier, but that resulted in people following this guide as opposed to the actual recipe docs.. So we prioritised the recipe docs instead. > that aside, if I understood correctly, there's no frontend login SDK currently for non-react apps ...., we can then use the supertokens-website lib for session management, correct? That is correct! > but that's non-existent in the latest version That docs are wrong. I have updated the docs (needs a hard reload since you must have cached the older version). You want to use the

providers

array. > the #3 shares the same init signature as #1, if #2 suggests it's both sign in + sign up in one go via ThirdParty.signInUp(), how does #3 behave with ThirdPartyEmailPassword.signInUp()? Think of these recipes as independent.. if you are using

ThirdPartyEmailPassword

, don't worry about the other two recipes at all..

@User one idea to easily see changes across versions would be be go to the examples folder in supertokens-auth-react GitHub repo, find the example that matches your use case, and see the commit history. This way you can see exactly how the version change affects the code

Awesome. That makes sense to me

If you can’t find the relevant commit, please let me know (along with your current versions and which example you are looking at)

What else does the

.middleware()

do aside from initializing the auth routes? If I want to implement my own routes, I can skip this and use the recipe APIs directly right? What will I miss by doing so? My scenario is that I don't want all of the extra fields, validations and post sign in and up handlers all cluttered within the

supertokens.init()

.

So you should keep the

.middleware()

, but you can specifically disable the sign in / up API routes by setting

disableDefaultImplementation

to

true

in the

signUpFeature

and

signInFeature

objects when calling the

init

function: See https://supertokens.io/docs/nodejs/thirdpartyemailpassword/init Then, you can create your own API route: - {authBasePath}/signinup POST (for sign in / up via social login): https://github.com/supertokens/frontend-driver-interface/blob/master/v1.7.0.md#url-apibasepathsigninup - {apiBasePath}/signin POST (for sign in via email password): https://github.com/supertokens/frontend-driver-interface/blob/master/v1.7.0.md#signin-api - {apiBasePath}/signup POST (for sign up via emailpassord): https://github.com/supertokens/frontend-driver-interface/blob/master/v1.7.0.md#url-apibasepathsignup When you create your own routes, make sure the path and method match the above API spec so that the frontend continues to work. Our implementation of these APIs can be found: - {authBasePath}/signinup POST: https://github.com/supertokens/supertokens-node/blob/master/lib/ts/recipe/thirdparty/api/signinup.ts - {apiBasePath}/signin POST: https://github.com/supertokens/supertokens-node/blob/master/lib/ts/recipe/emailpassword/api/signin.ts - {apiBasePath}/signup POST: https://github.com/supertokens/supertokens-node/blob/master/lib/ts/recipe/emailpassword/api/signup.ts

The middleware exposes APIs for sessions as well (to refresh the session), and also a bunch of APIs for reset password and email verification. So if you remove that, all these APIs will have to be provided by you

when you say "so that the frontend continues to work", that's only when using supertokens' provided frontend SDK which is only available to react only for now, correct?

correct

so yea.. if you are not using that, then you can create your own APIs that use the functions provided by our SDK

awesome, we use Vue so just wanted to clarify that part

but if you are using supertokens-website repo, then you will still want to keep the middleware for session related APIs