As I understand it (and I am pretty likely to get this wrong so feel free to
point that out) the only reason we have to send the user/pass on every http
request is because of the change to using postgresql to authenticate every
request (ie, server-side, LSMB logs into psql as the actual user), therefore
requiring the password to do so.
Let me try to answer this: see if I am right. (Chris?)
I am guessing that the user/password and any other session data is sent on every http request is to code in a RESTful way, ie with AJAX. This way a session's state is kept within the session, ie past back and forward with the data. The alternative is to either hold session state info on the server, in the hope that the session will be needed by future client requests, and then have to code stuff to manage this data, eg when to get rid of it, or else pass server-side info as cookies and code client side stuff to manage this data when its not needed.
I remember trying to make the point some time ago that maybe LSMB should
connect as it's own user, then use postgres' role-switching abilities to
become the connected user after connection.
That's not clear. Are you referring to the old "each user has his own app usename + there is one db account that the app code uses" vs "each user has his own application-username=db-username".
As I understand it this can be done without having to supply the user's password.
Whichever way usernames are set up, a username and password of one sort or the other still needs to be passed from the frontend to the backend at least for account creation and password changes. If this is encrypted in the frontend, then the same mechanism might as well be used to authenticate logins as well.
If all database access to the LSMB tables is to be via the LSMB code (or extensions) then a single db user account is fine. It is used by the application. I suppose that the source password for the application is in cleartext in the application's config file.