Hello together We are implementing SuperTokens within our application for the first time. First of a...
s
Hello together We are implementing SuperTokens within our application for the first time. First of all, the documentation and the coding examples on your webpage are great! I still got some questions though. 1. We would like to have an initial user within our database right at application startup. Is there a way to configure an initial admin user (not the db account)? 2. Regarding question 1. We thought about creating a user right on startup within our application but we consider this unsafe/vulnerable. I saw that other IDPs sort of work with a client-secret which could be safely stored. Is there a similar mechanic in SuperTokens? 3. Is there some sort of admin panel (UI)? As far as I'm concerned, I haven't found one or seen any notes about one. 4. We are using SuperTokens in a FastAPI(python) backend. I haven't found out how I can overwrite the SignUp method and make a role assignment right on signing up. I saw a few documentations such as https://supertokens.com/docs/userroles/managing-roles-and-users and https://supertokens.com/docs/thirdparty/common-customizations/handling-signinup-success but its hasn't worked out for me. Could you please provide us some python coding example?
n
Hi @sneaker_jan
About manually creating a user, you can do this on your backend by simply calling the sign up function exposed by the SuperTokens SDK (we can help with snippets here if you need)
You dont need to do this on startup everytime, just once should suffice
You can then use the user roles feature to assign an admin role to that user
For the second part this involves two things: - Overriding the sign up function to do some custom logic there - Using the user roles feature to assign a role to the user
Then in that you can consume the response after calling the function on
original_implementation
and use the user id to assign roles to them
s
Hey @nkshah2 thanks for the great response time and your support! Thanks, I will look into that docu. Regarding the other two questions. There is no such thing like a client-secret and there is also no admin panel UI right?
n
We are currently working on an Admin panel (we have a rudimentary one at the moment but it does not allow for user creation). Could you elaborate on what you mean by the client-secret setup?
s
We thought about doing an admin within the application on startup. As we evaluated through different IDPs we saw that a connection with an IDP usually needs a secret key (client-secret) which is provided by the IDP and needs to be configured within the app to get a connection. Now since we don't have such a secret, an attacker could call the core url and just create some users/roles himself.
I just checked the code again and saw that there is an api_key: # api_key="IF YOU HAVE AN API KEY FOR THE CORE, ADD IT HERE" I assume this might be what I have been looking for?
Regarding the Admin Panel. Nice to hear that, I will definitily be looking forward to this feature 🙂
n
Yep thats right, if you use the managed service of SuperTokens we provide an API key for you to use after you sign up. If you are using self hosted refer to https://supertokens.com/docs/emailpassword/quick-setup/core/with-docker#connecting-the-backend-sdk-with-supertokens-
s
Perfect, thanks a lot for your support! Really appreciate your help 🙂
n
Happy to help
s
Hey @nkshah2 I got some updates for you. The API Key worked out great! Unfortunately the SignUp Override didn't work as expected. This is the POC Code I implemented and the recipeList But in my frontend I receive an error 404 when posting the SignUp Form
The role user is existing in the db
n
@sattvikc Can help here
s
could u share debug logs?
you can set SUPERTOKENS_DEBUG=true env on your server
s
give me a moment pls
s
sure
s
Okey. App Startup Backend:
Frontend Call Logs
s
can u trigger the sign up call and share the logs for that
s
Backend Call Log
s
can u put this into a text file and share it here? it's a little hard to see thru screenshots
n
Looks like you are using thirdpartyemailpassword on your frontend but emailpassword on your backend, is that intentional?
s
I think the issue here is recipe is different between frontend and backend
s
Ah I just saw the log line. Wait I will check that on my end and then I will come back at you
in case something is still not working I will send you a text file 🙂
s
if you use the same recipe, it should work
having thirdpartyemailpassword on frontend and emailpassword on backend will not work
s
Ahh nice I see. It is working just fine. Even the poc code I have written to save the user (y)
Ah and I just saw that your docu also provides the override feature for thirdpartyemailpassword
got a little bit of time to get used to the documentation since you have so many different recipes and when I google for features sometimes I end up in the wrong recipe page. I guess thats how the error got into the code. Now as I'm aware of the problem I should be able to get it done
Thanks guys. Great support! 😄
s
cool, let us know if you face any issues
happy to help 🙂
8 Views