https://supertokens.com/
Join Discord
Menu
Home
Archive
Hello again people, context: we are using the self-hosted version of supertokens core in kubernetes ...
# support-questions-legacy
n
Hello again people, context: we are using the self-hosted version of supertokens core in kubernetes (with the help of helmchart mentioned here https://github.com/supertokens/supertokens-docker-postgresql/tree/master/helm-chart ) with 
thirdpartypasswordless
recipe , in 
golang
backend sdk (with gin framework) now, in the refresh session flow, the call to core at 
/recipe/session/refresh
from the golang-sdk is breaking i.e., for i tried manually calling supertokens core via cURL with:
Copy code
curl --request POST 'http://supertokens:3567/recipe/session/refresh' --header 'api-key: <api-key here>' --header 'rid: session' --header 'content-type: application/json; charset=utf
-8' --header 'cdi-version: 2.14' --data-raw '{"refreshToken": "<refresh token here>", "enableAntiCsrf": false}'
the response returned by core is 
{"status":"UNAUTHORISED","message":"java.lang.IllegalArgumentException: Illegal base64 character 25"}
So any help would be appreciated PS: when I tried the refresh flow locally, with docker image of supertokens core ran locally, the same call to 
/recipe/session/refresh
via golang-skd is getting response OK (with the same sdk version of supertokens in golang)
r
hey @nabeel4628
so the only diff between the two tries is that one uses the helm chart vs the other is just a local deployment without a helm chart?
n
right, only difference is that
r
that's odd
can i see the core's error log when you call this on the helm chart deployment?
the error logs that correspond to the refresh call above (which fails)
n
okay, checking the logs in the pod
hey @rp_st , have requested the devops team for the same, as i have permission constraints. Will convey the logs here as soon as they are provided. That's being said, thanks for the promt responses as always 🙂
r
Sounds good. It’s night time here, so in case you post the logs really late (for me), I’ll surely look at it as soon as I’m available tomorrow.
n
here is the specific log
r
Which version of the core is being used?
n
Copy code
image:
  repository: supertokens/supertokens-postgresql
  pullPolicy: IfNotPresent
  # -- Overrides the image tag whose default is the chart appVersion.
  tag: "3.14"
r
and when you tried locally, did you use the same docker image tag as well?
n
for local , I simply used 
registry.supertokens.io/supertokens/supertokens-postgresql
registry without mentions of any version
r
right. Maybe try with registry.supertokens.io/supertokens/supertokens-postgresql:3.14 and see if the error shows up in local as well
n
okay, chekcing
r
which operating system is being used on local vs in production?
Also, does this happen with all session refresh attempts in production? Or just one specific refresh token?
n
macOS Monterey on local and production it is linux
r
Which Linux distribution and version?
n
here is the info PRETTY_NAME="Debian GNU/Linux 11 (bullseye)" NAME="Debian GNU/Linux" VERSION_ID="11" VERSION="11 (bullseye)" VERSION_CODENAME=bullseye ID=debian HOME_URL="https://www.debian.org/" SUPPORT_URL="https://www.debian.org/support" BUG_REPORT_URL="https://bugs.debian.org/"
r
Ok thanks. Pls also answer the other two questions above
n
working fine with registry tag 3.14 locally here are the docker logs
Copy code
10 Mar 2023 15:38:45:525 +0000 | DEBUG | pid: 26cb8ae2-f561-4bd5-98de-242043cb19bc | [http-nio-0.0.0.0-3567-exec-8] thread | io.supertokens.webserver.WebserverAPI.service(WebserverAPI.java:157) | API called: /recipe/session/refresh. Method: POST. Version: 2.14

10 Mar 2023 15:38:46:039 +0000 | DEBUG | pid: 26cb8ae2-f561-4bd5-98de-242043cb19bc | [http-nio-0.0.0.0-3567-exec-8] thread | io.supertokens.webserver.WebserverAPI.service(WebserverAPI.java:182) | API ended: /recipe/session/refresh. Method: POST
and yes, on kubernetes, it is happening every time
on every refresh flow
r
Hmmm. Might be an operating systems issue then
Or rather a docker / Java issue
Can you please open an issue about this in our GitHub with all the above info? And we will have a look asap. Thanks
n
sure
r
Hey @nabeel4628
Would it be possible for you to SSH into one of the pods and try refreshing from inside the docker image itself?
n
yes, for that I'll be sitting with internal devop person, will update here about the outcome
r
thanks
n
hey @rp_st thanks for the patience so this is the situation while calling the 
auth/session/refresh
endpoint (which is exposed via supertokens sdk itself) from postman, it was not sending the sRefreshToken cookie in the request (reason being , the path of that cookie was set to 
Path=/auth/session/refresh
on the successful signin/up) however, we changed it to 
Path=/
and it started working. however, supertokens frontend sdk too, is not sending the sRefreshToken cookie due to this path reason i believe , hence it is showing error cc @anupam
apart from that, even while this end to end refresh flow was working after updating the cookie path, we tried to call the refresh endpoint exposed by supertokens core directly via following URL: 
curl --request POST 'http://supertokens:3567/recipe/session/refresh' --header 'api-key: <api-key here>' --header 'rid: session' --header 'content-type: application/json; charset=utf-8' --header 'cdi-version: 2.14' --data-raw '{"refreshToken": "<refresh token here>", "enableAntiCsrf": false}'
but it was failing on both, local docker and kubernetes on cloud with error message as :
Copy code
{
  "status": "UNAUTHORISED",
  "message": "java.lang.IllegalArgumentException: Illegal base64 character 25"
}
earlier when i told you that it was working on local, it was working when called via golang sdk on manually calling the supertokens core endpoint , it is failing on local as well
r
when calling the core api manually, from where are you getting the refresh token? The response headers? Or the cookie store on chrome? Cause i think when attaching to cookies, the value is base64 encoded - im not 100% sure of this (this is automatically done by the golang web framework i think)
a
@rp_st How much difference does the backend server url make? The cookie path is 
/auth/session/refresh
and our backend api url is 
/appname/auth/session/refresh
.
r
does the 
/appname
part get stripped away by something by the time it reaches the actual server code? If so, then you need to add the 
/appname
as the 
apiGatewayPath
on the backend's appInfo, and set the 
apiBasePath
to 
/auth
on the backend. On the frontend, you need to set the 
apiBasePath
to 
/appname/auth
.
n
@rp_st for base64 error, you are right, I was using the cookie directly from postman which was URL encoded. I have URL decoded the cookie and called the refresh endpoint of core directly, it is working fine
r
great! Im glad all issues are fixed now 🙂
79 Views
PreviousNext
Powered by

SuperTokens.com

SuperTokens is an open source authentication solution offering features like: Different types of login: Email / password, Passwordless (OTP or Magic link based).

Powered by