implement auth request queueing

[theferrit32]

currently session/token exchange happens on a single, static port. This process is pretty fast, much less than 1 second, but if two (or more) connection login requests overlap in this period, the latter connection will fail and not be authenticated.

example test: for i in {0..10}; do (ils &); done

in the above command, around 5-8 of the 10 requests fail on my machine.

Either use a condition variable to exclude the code using that port, or maybe a more explicit queue structure. The explicit queue structure could also be useful in associating callback nonces with client requests.

[theferrit32]

Very strange behavior using parentheses to background subshells in bash.

The following command launches 10 ils processes which overlap over each other, and all of them succeed in listing the actual irods directory for the current logged in user.

ils & ils & ils & ils & ils & ils & ils & ils & ils & ils 

The following command launches 10 ils processes in a for loop using parentheses subshells which overlap with each other, and most of them fail and think they are supposed to be listing the irods directory for the 'rods' user, which is not the currently logged in user:

for i in {0..9}; do (ils &); done

This does not occur when logged in as the system user 'irods' and running commands as the irods user 'rods'. All succeed. Suggests it is related to the auth plugin.

[theferrit32]

Verified that authorization periods can overlap as of this commit: c325beec06b70c063384c7ee598e4dfeb841b8a6

Callback requests from the openid provider can also be received and returned to the proper plugin instance in a different order than the authorization processes were started (iinit).

• Two system users (separate ~/.irods directories)
• Two irods accounts, with the subject id linked to their account (iadmin aua)

Process: 1) Run iinit for both system users, one directly after the other. 2) Now each of their agent-side plugins is waiting on the redirect_server mechanism to receive the authorization callbacks from the openid provider after the users log in using a browser. 3) Each user can browse to the proper authorization url provided to them by the plugin.
4) The redirect_server will receive reach callback from the openid provider after the user logs in. 5) The 'state' param on these requests map to the auth request instances from the irods plugin. 6) The redirect_server will route the authorization_code from these callbacks to the proper agent-side plugin through a Unix domain socket they are waiting on (up to 30 sec). 7) Each agent-side plugin will proceed with their process of exchanging the authorization_code for the id_token, access_token, and refresh_token. 8) The client-side plugins waiting on their corresponding sockets will receive the user/session information as well as the actual rcAuthResponse response, and exit.