Hello, we are pretty new to SuperTokens and I am e...
# support-questions-legacy
y
Hello, we are pretty new to SuperTokens and I am exploring its capabilities. We are trying to implement 2 ways of communication with SuperTokens. 1. Our frontend to our backend. (Should be fine) 2. Third party to our backend. Right now, I am trying to implement the 2nd one, I tried to use the emailpassword way to do it to test. Basically I created a signin function to send post request with the email and password to the Middleware, get the response and set up the cookies (access, front and refresh token), same for signout and signup. The problem I am having is that whenever the access token expired (refresh token is still alive), it won't generate new access token (even though I sent a request to the /auth/session/refresh). Another question is there a suggested way to implement third party to our backend communication authentication with SuperTokens?
r
hey @y.s_
Could you elaborate on the second use case more please? How do you define a third party here?
y
Erm, like a server to our backend
r
right. So why would that server need to do email password login?
cause usually server to server is via api keys or access tokens directly.
y
Yeah i understand that, right now I am just testing how it works
r
ah ok. So for baceknd to backend, this might help: https://supertokens.com/docs/microservice_auth/introduction
y
Okay thank you!!
@rp_st Hi again, so hypothetically, if user were to communicate directly to our server with their server using email and password (still a discussion among the team), they would receive the access token and refresh token, when the access token expired, it would make a request to the /auth/session/refresh route by Middleware. However I tried it, I sent a request to that api route, but got 401, unauthorized message, even though my refresh token is still alive
Why is that
r
the auto refreshing only happens using our frontend sdk which is meant for frontend clients
for server to server, you would have to make the refresh API call yourself, and the result woul be a new refresh token and a new access token which you can use in the future.
y
Yeah, I made the request call manually, but it return unauthorized message, 401
r
how are you making the request?
y
something like this
Copy code
@supertokens_blueprint.route("/test-refresh", methods=["GET","POST"])
def refresh_token():
    url = "http://localhost:5000/auth/session/refresh"

    try:
        response = requests.post(url)
        if response.status_code == 200:
            access_token_expiration_time = datetime.utcnow() + timedelta(seconds=180)
            access_token = response.headers.get("st-access-token")
            resp = make_response("Refresh successful")
            resp.set_cookie("sAccessToken", access_token, expires=access_token_expiration_time.strftime('%a, %d %b %Y %H:%M:%S GMT'), httponly=True, path="/", samesite='Lax')

            return resp
        else:
            data = response.json()
            return data['message']

    except requests.RequestException as e:
        return f"Error during refresh: {str(e)}", 500
r
are you providing the refresh token in the refresh API?
As an authorization bearer token
y
I think so
r
i don't see that in the code above though
y
Copy code
@supertokens_blueprint.route("/test-login", methods=["GET", "POST"])
def test_login():
    url = "http://localhost:5000/auth/signin"
    try:
        response = requests.post(url, json=payload)
        
        access_token = response.headers.get("st-access-token")
        front_token = response.headers.get("front-token")
        refresh_token = response.headers.get("st-refresh-token")

        if access_token and front_token and refresh_token:
            access_token_expiration_time = datetime.utcnow() + timedelta(seconds=180)
            refresh_token_expiration_time = datetime.utcnow() + timedelta(days=1)
            resp = make_response("Login successful")
            resp.set_cookie("sAccessToken", access_token, expires=access_token_expiration_time.strftime('%a, %d %b %Y %H:%M:%S GMT'), httponly=True, path="/", samesite='Lax')
            resp.set_cookie("sFrontToken", front_token, samesite='Lax')
            resp.set_cookie("sRefreshToken", refresh_token , expires=refresh_token_expiration_time.strftime('%a, %d %b %Y %H:%M:%S GMT'), httponly=True, path="/", samesite='Lax')
            return resp
        else:
            return "Missing tokens in the response headers", 500
this is the test-login, not sure whether i set the cookie correctly
r
im a little confused at what you are trying to do
why are you setting the refresh and access toke in the response
y
I am trying to set cookie in flask, then use it to access protected route
It does work when I want to access the protected data, but not the refresh token route
r
why arent you just calling the sign in API that we have directly from the frontend?
y
Because there might be a feature that we want to implement in the future where the user can directly communicate with our backend server using email and password
r
well in that case, in the above code, why are you seeting the access and refresh token in the response? Isn't it all just backend to backend? So shouldnt you save the tokens in the db or somewhere?
y
Yeah yeah, will do that later, but currently just testing the function
r
righ
so when you make the refresh API call, how are you adding the refresh token to the request?
y
part of the cookie in request header no?
so u mean like the token should be part of the payload when sending the request?
r
No it can be a part of the cookie in the request header as well, but where are you attaching that cookie? In the core above, i don't see any headers being added to the refresh POST API call.
y
hmm, I didn't attach it, but it is showing that the refreshtoken is part of the request headers already
r
how is this showing on the browser?
aren't you doing m2m? How is the browser involvedD?
y
hahaha, we use python flask as our backend, I am just creating extra route to test
r
sorry, but your setup isn't clear. The refresh API request needs to the refresh token. So when calling it from your backend, make sure to add it. The screenshot above indicates that it's being transferred from your frontend to your backend (Cause it's a browser screenshot), but from there on, im not sure what you do with the refresh token.
you could enable our backend sdk debug logs and try and figure it out yourself 🙂
y
Ahh okok, thanks man, sorry for causing inconvenience😂
r
no worries 🙂
36 Views