Any ideas?
j
Any ideas?
r
Any ideas?
Hey!
Use this thread @User @User
j
Ive been manually hitting endpoints through the browser
n
Just to clarify, you’ve hosted the SuperTokens core yourself but haven’t used any backend sdk yet?
r
Are you querying your frontend url or backend url?
Not sure what you mean by that
Im querying supertokens directly right now
r
The core?
Please see the architecture diagram
j
One moment, let me take a look
r
And setup the frontend / backend SDKs
There are two sets of APIs
One for the core, and one exposed by the backend SDK
j
Right so
Im trying to ping the bottom part there
r
Not sure what you mean by bottom
Left or right?
j
the second one in the "Your Backend API" section
the lower one
n
So there’s three parts to using SuperTokens, you need the core which you have hosted yourself
j
right
n
You need the backend sdk that exposes the APIs to you
Which is the middle bit you’re trying to query
j
So the SDK is what lets me programmatically access supertokens. RIght?
n
And exposes api routes on your server (to call things like /auth/signin etc)
j
Right, but why cant I just make a request to the core directly?
It's just a rest api right?
j
Right now Im using the Signin/Signup recipe and Im getting 404s with that too
n
That’s the spec for APIs exposed by the core, if you wanted to call it manually
j
Yea, so Im looking at that and Im getting 404's
n
The URL you sent earlier doesn’t match the spec
j
That may be the issue. Let me relook at that
n
Also while you can query the core directly, I highly recommend using one of the backend sdks. It makes the whole process much simpler
j
Right, thats the plan
n
But for testing you can use that spec
j
But I need to figure out why its not responding with anything
I looked at the spec. Seems to match
How would you change it to match?
n
Right so that’s a different spec
That’s the spec for the frontend to query the backend sdk
The one I sent is the spec for communicating with the core
If you look at both, the routes are different
j
Oml. Okay so I clicked the link you gave me and Im getting responses now.
Thats a bit confusing
n
Like I said there’s 3 parts to SuperTokens in most cases, so 2 specs for the two pairs
j
So then I guess what I dont understand is what is the frontend doing? Because it is querying something and getting 404s
I clearly misconfigured something
n
So you hosted the core, which your backend communicates with
j
So there are 3 restful API's?
or 3 parts generally
n
3 parts but 2 sets of APIs - between your backend and the core (the one I sent) - between the frontend and the backend (the one you sent)
j
Ah okay. I see
Why was it designed this way? Just curious.
n
Out of curiosity what part of the architecture diagram confused you in this setup? So we can improve on it
j
If Im being honest, the documentation overall was really unclear
n
Hmm, we would love to hear some specifics. I do agree things can be improved but hard to do that without feedback :p
j
In this image it isnt clear what is happening to me.
All im seeing is that there are some endpoints
r
Did you see the diagram below?
And walk through how that works?
j
The sign in and sign out flow?
r
Yes
j
I havnt even looked at it yet.
I didnt realize that I should have looked at it
r
Hmm.
n
Yep that’s probably where the confusion comes from, something we need to iterate on for sure then
Thanks for the feedback!
j
So after looking at the second chat. The system makes more sense. But Im confused, what exactly is a "session" in this case?
I assume it's different from sessions in PHP?
n
It’s just a conventional session, the best way to look at it is that your backend systems are split into the backend sdk and the core
j
Right, so the whole system is stateless then?
holly molly
it works
thanks!
r
Yes. It is.