Hi, Zeno. You don't need any permissions at all to POST to the /authn/login endpoint (by design, because of course you don't have any permissions before you log in), so there is nothing special needed for that.
You're correct (as far I as can tell) that edge-patron doesn't give the ability to manage the user's address, so if you want to build that capability into your OPAC, you'll either need to code directly to the FOLIO API or write your own application for managing patron address updates. You may want to consider which is better from a security perspective, because there is not a way to grant only the ability to modify the logged-in user's own user record. mod-users-bl does offer a separate endpoint for getting the logged-in user's data (the /bl-users/_self endpoint), but that endpoint only supports GET.
I can think of 4 possible strategies for managing this requirement:
- Raise an issue on the mod-users-bl project in Jira (https://issues.folio.org/projects/MODUSERBL) to support PUT (or PATCH) on the /bl-users/_self endpoint. Work with the project owner (I think Khalilah Gambrell) on prioritization for development. I think this is probably the best solution of the ones I list here, but I don't know if it will fit into your time requirements.
- Create a system user for your OPAC, using a similar strategy to the edge modules. Grant that system user the permissions needed -- for this, just the permission users.item.put (the endpoint is /users/{id}). Code directly to the FOLIO API, acting with the credentials of the system user. You would need to put some protections (both in your code and in your network) around granting this permission. Obviously this carries more risk.
- Grant the permissions to your users to be able to update user records. Code directly to the FOLIO API, acting with the credentials of the user. I suspect this is the most risky proposition, as you are granting to all your users the permission to update all user records. I don't think it gains you anything in security over option #2 (except possibly a better audit trail), and it requires that every time you create a user record, you have to also managing granting the permission.
- Write an application that manages address changes outside the FOLIO API (a simple database application, for example). Use a process outside your OPAC (so presumably more controlled and secure) to update the user records, for example, a script that interacts with the FOLIO API using system user credentials. I've done something like this myself to work with other systems that don't have an API. It's not very elegant, but might meet your requirements.
Any other thoughts? I hope this is somewhat helpful.
wayne