but if you are worried about secret key being compromise, then you should know that the keys are changed regularly (the older ones are immediately revoked).

And we do this without any user logouts... so really, using

SHA512

over

SHA256

wouldn't make too much of a difference.

understood. Thanks for the quick replies 🙂

I have a few more questions: 1. Can we inject supertokens as a middleware in our java services instead of having a dedicated service? 2. How does the solution take care of CSRF?

> Can we inject supertokens as a middleware in our java services instead of having a dedicated service? No. The superotkens core needs to run as a dedicated http service. If your backend is in Java, we only have a Javalin SDK at the moment. > How does the solution take care of CSRF? https://supertokens.io/docs/session/common-customizations/sessions/anti-csrf

we are using spring webflux for our java services calling a dedicated API for each request might slow us down

The session verification on the backend happens in a stateless manner. That is, it doens't query the core for session verification. It queries the core only for creation, refresh, recoking of sessions.

unfortunately, we don't have support for spring webflux at the moment.

According to this text: "The frontend sends the access token for each API call that requires session authentication. These API calls verify the access token and its expiry. If verification fails, the API throws a session expired error, else, execution continues." Won't by backend API need to communicate with Core for verification of access token each time?

No. Cause the access token is a JWT. So they can be verified in a stateless manner using the public key of the private key that is used to sign them

right, yes.. got it..infact my backend APIs dont need to communicate at all with core, only frontend needs to.. our frontend is in react js

Our architecture is such that the frontend communicates with the core via your backend API domain. This is because session cookies are to be set against your API domain. To achieve this, you can run a node process that uses our NodeJS SDK, and have a reverse proxy (using Nginx) in your backend that routes all /auth/* requests to that node process.

ok, since we use AWS ALB, routing can happen at that layer I guess regarding the 2nd point, we could still use javalin SDK from our java layer?

> we could still use javalin SDK from our java layer I'm not sure about compatibility of javalin and spring. So not sure.. what's your timeline for implementing auth? And are you looking to implement login + sessions or just sessions?

just sessions

alright. And what's your timeline for implementing? Would you be willing to wait a few weeks for us to implement a spring supported SDK? This way, you wont need to even use the reverse proxy technique.

that would be great, our production rollout is around a month away

could you pl give me a rough timeline of when a spring supported SDK could be available?

@User anytime in the next 2 months it seems.. could be a few weeks from now till up to 2 months.

Using

EmailPasswordReact

I want this

width

override to apply to the mobile size media query only. It seems there is no way to override mobile width? Mobile uses

95vw

by default which isn't great when the NextJS

App

component has padding.

I can solve by removing the padding for auth routes in

App

but it's more complex so just wondering

you could use JS to detect what type of device the user is using and based on that, you could set the value of

width

?

My point is that your media query overrides the width. It isn't used under 441px screen width

And because it's shadow DOM it can't be targeted with CSS either

> And because it's shadow DOM it can't be targeted with CSS either You can disable the shadow DOM by setting

useShadowDom

to false in the init function

Okay good to know

With shadow DOM disabled and using CSS I am able to override. Thanks for your help and the packages @rp!

happy to help 🙂

I’ve implemented login and authz, coupled with sessions using supertokens... and fixed all the new bugs I created. The UX is still kind of garbage though— would love to replace some of this code. Any update on ETA for golang SDK catching up to latest core / supporting some of the HEAD scenarios?