Medusa Eats Auth

[wind shore]

With regards to the Medusa Eats demo, I'm looking into the security vulnerabilities that could potentially come up with the auth register endpoint. As the endpoint stands, it is setup to register and authenticate a new session which we later tie to either a restaurant admin or driver. With the existing logic, we are potentially allow for drivers to access data the they shouldn't access, such as listing all drivers (we potentially wouldn't want drivers to see other drivers info).

But more concerning, a malicious user could potentially register a new auth and then create a driver. Technically shouldn't we limit the creation of a driver or restaurant admin to a user admin only?

Also note, I do understand that this is a recipe so the answer might be that this was done so intentionally for the purpose of the demo 😇

Thanks again - I ask to better understand best practices when it comes to using auth for creating different types of users.

Also would be good to look into stale auth register instances and how we could potentially prevent / delete these instances if after a certain time period they aren't tied to a real user type.

[wind shore]

Bumping for greater visibility 😇

I think we should potentially have the option to remote an auth id so that for example when we delete a driver we also delete it's related auth and therefore completely delete the entire user. Otherwise, we could potentially delete the driver's account but they'd still have access to driver data as long as they authenticate via Curl commands