Due to certain requirements/constraints, I'm wondering about sending user login and password with each request.
This somehow doesn't feel very good to me, though I think for my particular case, it could make sense: it would reduce the number of HTTP requests , reduce the latency and simplify frontend code.
Here is the situation:
- Traffic to server comes from a mobile app
- All the traffic goes through HTTPS
- We keep user credentials encrypted in the device storage to log users in automatically on each app boot
- Server side session timeout is very low (few minutes) and is beyond my control
- The DB is beyond my control; I can not add anything to the DB easily and quickly (it would be quite a challenge to get a DB field if e.g. I wanted a long-lived session token)
- The traffic in the app usually happens in batches
- The typical traffic batch within the session timeout is just a few HTTPS requests
- Since the traffic comes from mobile app, sending "keep session alive" requests is not always possible; if the user kills an app and relaunches a few minutes later (or minimizes for a few minutes), there's no possibility to keep the session, and I need to relogin the user.
So, the typical traffic pattern currently is:
#USER OPENS THE APP POST /autologin -> response: [ok, here's the new sessionid]|[auth failure, maybe the password changed since] #SUPPOSING AUTH WAS OK; USER BROWSES AROUND THE APP POST /someAction1 POST /someAction2 POST /someAction3 #USER IDLE FOR A FEW MINUTES POST /keepSession ... #USER MINIMIZES THE APP #USER RELAUNCHES THE APP, MAYBE SEVERAL MINUTES LATER, MAYBE NEXT DAY POST /someAction4 -> response: sessionTimeout POST /autologin -> response: [ok, here's the new sessionid]|[auth failure, maybe the password changed since] #SUPPOSING AUTH WAS OK; USER BROWSES AROUND THE APP POST /someAction4 ...
So anyway, on average, I have to send the login request quite often once the session expires; significant percentage of requests are login requests.
If I send login and password in each request, I can
- get rid of
/autologinrequests at the boot
- get rid of
/keepSessionrequests every few minutes while user is active
- get rid of
/actioncombo in case of session expired; down from 3 request to just 1
I could just always send both the sessionid and login+password, then on backend reuse sessionid if still valid, otherwise create a new session using the login and password, and do whatever I wanted within the same HTTP call, without the need to play ping-pong between frontend and backend.
To sum up, from my perspective:
- I'd have to take care on backend to not accidentally log user credentials in multiple request handlers, not just a one (login handler)
- it could increase the number of requests with login and pass in payload maybe by a factor of N =~ 4,
- overall number of HTTP requests done by server decreased by some 20%+
- no need for frontend logic to maintain the user session; just shoot every request with credentials. If it fails due to auth issue, log out the user.
Knowing that the traffic is HTTPS encrypted, are there any severe downsides to my always-send-login-and-pass aproach?