Reputation: 14038
I'm planning on incorporating the Gearman job server into my website's architecture. One task in particular that I'm planning on using gearman to accomplish is Facebook authentication with my website.
Currently, I allow users to log into my site by authorizing my Facebook App via the Facebook JS SDK, after a successful authentication I send the user's access_token to my server via an AJAX call and once the server has the access_token it queries the facebook Graph API to get the current user's info and I set the user's session accordingly. I would like to push the facebook API call off to a worker thread.
I would send the job to gearman, have gearman return a delayed job id, send that ID back to the client's browser, and have the browser poll the server at set intervals (prob 0.5 or 1.0 seconds) to see if the API call has completed by returning the job ID to the server and having it check the job's completed status.
My question is: are there any security risks in sharing an internal job identifier with the client?
Upvotes: 1
Views: 528
Reputation: 52832
The sharing is probably not the issue, but since the user is submitting the jobDd back to the server to check the status, there's nothing stopping the user from just changing the jobId and getting the state of other authentication attempts. This might not be a problem (as you probably wouldn't return anything else), but you'd be leaking at least a bit of information about the popularity of your app to any competitors.
I'd suggest simply generating a random key server side and associating the job id with that key, then using the random key to communicate between the browser and the server to request the current state.
The client would get the random key and then use that for requesting the state of a current task, while the server acting between the client and Gearman would look up the key in the database, retrieve the actual jobId and then query Gearman.
Upvotes: 1