PublicQueueTask5: PIN to protect queue
A queue creator can optionally choose to protect his queue by using a 4 digit pin. Then he can keep refreshing the pin whenever he wishes to.
While creating a queue, we can take as a boolean 'isPasswordProtected'.
If so, a random 4 digit number is to be returned. There should also be a api for the admin to request a new random number.
Similarly, while joining a queue, if the queue is password protected, the user should be asked to s enter the PIN. We should have a queue information api, that the UI can call for knowing more information on the queue. The API can return queue name, current number of people in the queue, and also if it 'isPasswordProtected'.
(The APIs will be much cleaner once we have @thehamzarocks 's #16 and auth.)
@avinashkris9 This is a nice task, you want to take it up?
I can try. I have some doubts
- Post request on
/queue/createwill have isPasswordProtected field. Can client send a pin when sending create request or is it always server responsible to generate pin ? - if isPasswordProtectedField is yes, a 4 digit random pin should be generated and send through response body.
- Post
v1/user/addshould have pin while adding user. How the pin should be passed ? Header/Request body? - Queue info api is that the same
/v1/user/status? - Is there any spec or uri decided for random pin generation.
- Let's generate the PIN. It would be cleaner UX. Otherwise the user would have to think of one and type it. Most systems are designed like this.
- Right
- Request Body
- Good question. Yes. it's the same for now, but I have plans to have two separate APIs later.
- Nothing fancy,
new Random(System.currentTimeMillis())should work, in my opinion.
How is the pin stored and validated ?
The pin is stored in the queue table. Validation is manual, we will have to check the pin from the user against the pin from the db.
The join queue form will send a queue status request when the page loads, it will have a boolean field isPasswordProtected that if set to true, the UI would have to ask the user for the PIN.
The admin would also have a button somewhere to reset the pin with a new one.
Just a suggestion encrypt (not encode) the pin before storing it in db , will be a good practice
From what I think, these are the reasons why we encrypt data:
- We hash passwords so that even the website owners can't read it.
- We encrypt sensitive information, like credit card info, biometrics etc. so that if we get hacked and the data gets stolen, it doesn't create problems.
Our queue password, is a random 4 digit pin that we store. Think of it like a bluetooth pairing code. I don't see a need to encrypt it.
In the event of a hack, I'll be more concerned about the name and mobile number that will get leaked.