Ok thanks.. So since I'll be using a chrome extens...
# support-questions
s
Ok thanks.. So since I'll be using a chrome extension could I leave the websiteDomain as * ? appInfo: { appName: "CleanVid", apiDomain: "https://cleanvid-api.netlify.app", websiteDomain: "*", apiBasePath: "/.netlify/functions/auth", },
r
Ok thanks.. So since I'll be using a chrome extension could I leave the websiteDomain as * ? appInfo: { appName: "CleanVid", apiDomain: "https://cleanvid-api.netlify.app", websiteDomain: "*", apiBasePath: "/.netlify/functions/auth", },
Give me a moment please
@User you can set the websiteDomain to something like
https://example.com
. It doesn't really matter in this case.
You cannot pass * as a domain name
yo uwill have to pass some domain name. Since yours is a chrome extension, you can use something like: https://example.com
s
okay trying that
r
Also note, that your apiDomain should be the same as the domain you are querying. SO if you are using localhost for testing, you should set it to localhost in the testing env.
(along with the port if any)
s
okay so can I test this via postman, I now get this error : {"error":"The middleware couldn't serve the API path /.netlify/functions/auth, method: post. If this is an unexpected behaviour, please create an issue here: https://github.com/supertokens/supertokens-node/issues"}
r
Can I see the code you have written for the lambda function?
s
I just using the session, so I'm following this guide : https://supertokens.com/docs/session/introduction
serverless netlify
r
Yes. So can I see the code for the netlify function you are trying to test?
s
"use strict"; let supertokens = require("supertokens-node"); let { middleware } = require("supertokens-node/framework/awsLambda"); let middy = require("@middy/core"); let cors = require("@middy/http-cors"); let { getBackendConfig } = require("./../config/supertokensConfig"); supertokens.init(getBackendConfig()); module.exports.handler = middy(middleware()).use( cors({ origin: getBackendConfig().appInfo.websiteDomain, credentials: true, headers: ["Content-Type", ...supertokens.getAllCORSHeaders()].join(", "), methods: "OPTIONS,POST,GET,PUT,DELETE", }) );
r
And the rrequest you are making is to which API?
r
I see. no such API exists that is exposed by that middleware
there are only two APIs exposed by the session recipe as seen here: https://app.swaggerhub.com/apis/supertokens/FDI/1.12.1
signout and refresh
You should see the reference for creating a new session: https://supertokens.com/docs/session/common-customizations/sessions/new-session Basically, your frontend calls your API to login the user and that then calls the
createNewSession
function
the
createNewSession
function attaches session tokesn as cookies and sends it to the frontend. The frontend then sends the access token to your API which can use the
verifySession
function to verify the session. If the access token expires, the frontend calls the refresh API (Exposed by the middleware you implemented above). If you call the sign out function on the frontend via our SDK, it calls the sign out API exposed by the middleware as well.
That's how it works
s
so then what the auth for ?
r
what do you mean?
s
why did the guide have me create the auth function ?
r
Cause those need to expose the session refresh and sign out APIs
which is used for session management.
s
this is very confusing
r
So you have login and you have session management
login is something that you have made already.
Which means, you have an API that the frontend calls for logging a user?
s
yes
r
what's the path to that login API?
s
login-user
const mysql = require("mysql2/promise"); const bcrypt = require("bcrypt"); exports.handler = async function (event, context, callback) { const sendSync = async () => { try { let body = JSON.parse(event.body); const { PLANETSCALE_CONN } = process.env; const connection = await mysql.createConnection(PLANETSCALE_CONN); const { password, email } = body; let [rows] = await connection.execute( "select id, email, hash, first_name, last_name, signup_date, subscription_date, sms, status from users where email = ?", [email] ); connection.end(); console.log(rows); if (rows.length > 0) { const user = rows[0]; const { hash, ...rest } = user; const userWithoutHash = rest; await checkUser(password, hash, userWithoutHash); } else { send({ match: false, user: {} }); } async function checkUser(password, hash, user) { //... fetch user from a db etc. const match = await bcrypt.compare(password, hash); if (match) { send({ match: true, user: user, message: "Welcome back" }); } send({ match: false, user: user, message: "Not a valid user" }); //... } //send({ message: hash, pwd }); } catch (error) { send({ match: false, user: {}, message: error }); } }; const send = (body) => { callback(null, { headers: { "Access-Control-Allow-Headers": "Content-Type", "Access-Control-Allow-Origin": "*", "Access-Control-Allow-Methods": "POST", }, statusCode: 200, body: JSON.stringify(body), }); }; await sendSync(); };
r
/.netlify/functions/login-user?
s
yes
r
ok great,
So in this API, after you have successfully verified the credentials, you need to create a session - correct?
s
yes
r
So to do that, supertokens has a function for you called `createNewSession`: https://supertokens.com/docs/session/common-customizations/sessions/new-session
You can use that function in this API
What this function will do is that it will create new access and refresh tokens and attach them to the response cookies - which are sent to your frontend (As cookies)
Makes sense so far?
s
this is in type script, my functions won't work with typescript
r
you can convert ts to js very easily.
and our SDK works with JS too
so once the frontend gets the cookies, you can call your APIs from the frontend and the browser will attach the access token automatically.
In order to check the access token in the API, you need to use our verifySession function a shown here: https://supertokens.com/docs/session/serverless/with-netlify/session-verification
s
awsEvent: SessionEvent so where is the event coming from ?
r
Now when the access token expires, the frontend needs to refresh the session. For this, you need a refresh API on the backend. This refresh session API is what is exposed by the auth function you implemented previously.
I hope this makes sense now. If it doesn't, then i think you might want to spend more time reading the docs and seeing the examlpes
s
okay let me play around with this a little bit more
r
it might be a little confusing at first since this is a new type of framework.
But once you understand it, it's intuitive and provides exactly what you are looking for.
2 Views