https://supertokens.com/ logo
Join Discord
Powered by
SESSION STILL AVAILABLE AFTER REVOKING IT
# support-questions-legacy
n
SESSION STILL AVAILABLE AFTER REVOKING IT
after solving the auth guard and session decorator issues, i started making cross checking around the sdk to make sure everything work. whats strange is, after social login, if I revoke the session from the dashboard i still get user infos and protected api results in the frontend
r
thats cause the verification is statelss. If you wait for the session's access token to expire (1 hour by default), the refresh will fail logging out the user
if you want immediate revocation, search for access token blacklisting in the docs
n
so, just to undestand, logout do revoke and blacklist the token?
r
Logout clears the session from the frontend as well. That’s why it’s instant
Whereas from the dashboard, it’s in offline mode, so that doesn’t clear the session from the frontend. Which is why a refresh is needed.
n
ok, quite clear, now:
i have an angular frontend, generated by your tool. It has a guard for the main route and the guard itself works. the backend has protected apis. if the session is expired, a call from the frontend (without realoading and so without the guard being executed) reflets in a refresh call that fails (unauthorised)
r
Yup. That’s expected
n
a few days ago I asked u about the needing of an error interceptor in the frontend, u answered in a pre built ui it woultnt be needed and a failing request towards a protected api would have generated (i imagined) a sort of redirect
r
Ahh I thought u were using full react
For non react apps, you would have to catch these 401 errors and redirect to the auth page
n
ok i talked to you.. very well 🙂
ok that sounds 😉
just curious: is this indicated in the docs? did i fail looking for it?
r
I don’t think it is.
n
ok thanks
can i continue bothering u? i get this:
Copy code
bash
Serving on http://localhost:3000
[Nest] 1  - 12/29/2023, 1:44:31 PM   ERROR [ExceptionsHandler] RESPONSE_SENT
Error: RESPONSE_SENT
    at AuthGuard.canActivate (/home/src/app/dist/auth/auth.guard.js:48:23)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async GuardsConsumer.tryActivate (/home/src/app/node_modules/@nestjs/core/guards/guards-consumer.js:16:17)
    at async canActivateFn (/home/src/app/node_modules/@nestjs/core/helpers/external-context-creator.js:155:33)
    at async target (/home/src/app/node_modules/@nestjs/core/helpers/external-context-creator.js:73:31)
    at async Object.tests (/home/src/app/node_modules/@nestjs/core/helpers/external-proxy.js:9:24)
[Nest] 1  - 12/29/2023, 1:44:31 PM   ERROR [ExceptionsHandler] Cannot set headers after they are sent to the client
Error [ERR_HTTP_HEADERS_SENT]: Cannot set headers after they are sent to the client
    at ServerResponse.setHeader (node:_http_outgoing:652:11)
    at /home/src/app/node_modules/@apollo/server/dist/cjs/express4/index.js:36:21
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
/home/src/app/node_modules/supertokens-node/lib/build/framework/express/framework.js:155
            return next(err);
                   ^
TypeError: next is not a function
    at SupertokensExceptionFilter.handler (/home/src/app/node_modules/supertokens-node/lib/build/framework/express/framework.js:155:20)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
Node.js v20.10.0
on the first unauthorised api call
this is on the suggested authguard from ur docs (not the modified version where I added the graphql handler
r
We have a check in our guide in the error handler where we check if a response is already sent or not. Can you check if you have added that?
n
do u mean this
Copy code
typescript
      if (res.headersSent) {
        throw new STError({
          message: 'RESPONSE_SENT',
          type: 'RESPONSE_SENT',
        });
      }
in the authguard?
r
The exception filter
n
this is part of the nestjs guide so is already implemented; that said, the filter is also affected by the context problem so I needed to modify it. what is not straight forward is the graphql error handling that differs from the errorrequesthandler
r
right. Im not too sure about the solution right now. Sorry. But if you open an issue about it, we can helpe out sometime next week.
n
in github?
r
yea
in the supertokens-node repo
n
ok thank u guys
since ur still there, about this answer, should i redirect to login page or try to refresh the token as reported here
Copy code
typescript
import Session from 'supertokens-auth-react/recipe/session';

function attemptRefresh() {
    Session.attemptRefreshingSession().then(success => {
        if (success) {
            // we have new session tokens, so we redirect the user back
            // to where they were.
            const urlParams = new URLSearchParams(window.location.search);
            window.location.href = urlParams.get('redirectBack')!;
        } else {
            // we redirect to the login page since the user
            // is now logged out
            window.location.href = "/login"
        }
    })
}
??
r
you can redirect to the login page.
since a 401 sent to you would only happen if the refresh failed from our interceptors.
n
interceptor in the front end or in the backend?
meaning: is the backend responsible for refreshing the token? postman behaviour is kinda confusing me
r
frontend
n
there is something not working: I revoked the session and waited for the token to expire. I kept calling the api from the frontend and until the token was still valid the interceptor was invoked, and correctly no error has been catched. this is the code for the interceptor
Copy code
typescript
import { HttpInterceptorFn } from '@angular/common/http';
import { inject } from '@angular/core';
import { Router } from '@angular/router';
import { catchError } from 'rxjs/operators';

export const authInterceptor: HttpInterceptorFn = (req, next) => {
  debugger
  return next(req).pipe(
    catchError((error) => {
      const router = inject(Router);
      if (error.status === 401) {
        router.createUrlTree(['auth']);
      }
      throw error;
    })
  );
};
after the token has expired instead I got refresh call failing with code 401
the call didn't reach the interceptor
r
the refresh call is done by the interceptor. Im not sure what you mean.
n
u told me since I'm on angular I need to implement my interceport. did I get something wrong?
r
you don't
you just need to catch 401 from your netowkr calls
n
in angular is done via interceptor
r
ah ok
is the intercceptor applied to the fetch / axios instance?
or xhr instance
n
interceptor applies to all http calls
r
can you add print statements in your interceptor to make sure it's going in there?
n
in case of refresh, my interceptor is not invoked, thats the point
the call stops before reaching the interceptor
what is the piece of code in supertokens-auth-react responsible for refreshing the token?
r
it's in a dependency of supertokens-auth-react. The repo is called supertokens-website: https://github.com/supertokens/supertokens-website
if you use fetch / axios, and then do this, the 401 error is thrown / returned to the user as normal. Im not sure why the angular interceptor is not able to get the error
n
this is the debug output
message
r
nothing seems to be wrong with this
how do you use authInterceptor?
also, does your interceeptor wrap our interceptor or the other way around?
n
i register the interceptor as a provider in the app module, it is the way to do that in angular. I don't know at what level your interceptor acts
r
you can add a console log in your intercceptor. If your console log comes after our frontend interceptor starts to run (you can enable frontend debug logs to see), then that explains why this issue is happening. You want to make sure that your interceptor wraps ours.
n
thats the point, my interceptor is invoked if the session is in validity, while in the case of the refresh call my interceptor (that is registered as app interceptor, so acts at all levels) is not even invoked
r
Can you see if your interceptor wraps ours or not? That’s important
n
since is not invoked, I'd say NOT otherwise it would stop there in the debug
r
Can you please check via debug logs?
The refresh api call is made internally in our SDK using fetch.
n
i've already checked, is not invoked
r
No I mean when you make a regular api call, what happens first? Ur interceptor or ours?
n
i should locate ur interceptor in the code
in supertokens-website/lib/build/fetch.js i put a breakpoint at line 950 
function getLocalSessionState(tryRefresh) {...}
and it get executed before my interceptor
this is intended for active section
now im waiting for the session to expire
r
That function can be called from other places too
You want your interceptor to run before ours in general
So that means doing supertokens.init before your interceptor is added
n
the problem was I wrapped the http request within a "if" block checking Session.doesSessionExists(), this prevented the http request from being called in case of session missing
17 Views
PreviousNext
Powered by