curveball/a12n-server

Question: is this for BE only (can I use it from React)?

Closed this issue · 4 comments

spidgorny commented

I like the idea of reusing the code written and tested already. And I like Curveball being native TS code.

I wonder if I can use this a12n-server as a backend for my React app. Does your /login and /register endpoints support replying by JSON? Is there a documentation for endpoints?

Or the whole project is meant for writing BE code in TypeScript?

evert commented

Hey @spidgorny ,

The intent absolutely is to have an API for everything. In fact, the intention was not have a front-end at all, and eventually build a good management interface that strictly uses the server via its API. Another goal is for the server to be 'install and go', and not need further customization for 80% of the use-cases.

However, not all of these APIs are done.

You can POST to the /user endpoint to create a new user, but there's no API yet to change passwords.

As for /login, if you want to control the username/password UI, you can use an OAuth2 "password" grant_type.

If you completely want to own the UI and handle this outside the application, there's likely a few other things you might run into. I would be happy to help you work through those barriers (and make the product better for everyone). So it might not be perfect for your use-case yet, but I would like to help get it there!

spidgorny commented

OK. Let's work together. I've created a new ApiController and the following routes:

  router('/api/isAuth', api.isAuth),
  router('/api/login', api.login),
  router('/api/logout', api.logout),

Will mimic your login/logout methods but make them reply with JSON.
Do you approve the approach?

spidgorny commented

You can check the code of api.ts.

evert commented

Hi @spidgorny ,

Logging in remotely and checking if a login is valid is in fact already implemented, sorry if that wasn't clear.

To do a password-based login, you can use the OAuth token endpoint with the password grant-type. This is really the most appropriate way to handle this at the moment.

To see if an OAuth token is valid, you can use the /introspect endpoint.

Logout is not yet implemented, but we want to use the OAuth2 'revoke' specification to handle this:

https://tools.ietf.org/html/rfc7009

If you feel up for the task to implement revoke, it would be super appreciated. But basically we want to steer people away from doing cookie-based logins remotely, and completely rely on OAuth2 features. This allows people to use generic clients that work everywhere and not lock into the a12n-server