Level 14
"Is this approach secure?" - no, what if I make the appointment request on desktop and open the email verification on my phone? I would not be logged in on mobile and therefore have no session.
Nov 8, 2023
8
Level 2
Verify email before storing data.
I am working on an appointment system where the patient must enter an email, date, and time. Before storing the appointment, I need to verify the email by sending a code. Therefore, I am considering storing these attributes (email, date, time, verification code, etc.) in a session until the patient successfully verifies their email. After verification, I will store the appointment in the database. Is this approach secure, and is there a better solution available?
Level 2
@krisi_gjika i'll verify the email by sending a code so you just enter the code. What's wrong!! 😅
Level 6
storing information in a session before email verification is not a secure approach. sessions are typically stored on the server, and although they can be made relatively secure, they are not the ideal place for storing sensitive data such as email, date, time.
I guest you just need clean database with minimal unnecessary data, so you don't want to save this unverified email in database table.
but let's see how the standart laravel technique for this email verification.
you can still save the data in database table, even the email is not verified. you need the column verified_at with datetime type and allow null. if the email is verified add the value date and time when email is verified. so if this column is not null, email is surely has been verified.
and how about other unverified email ? you can delete it by do a scheduled task or cron job. you can arrange the time as you need. like three days after the email is first created/saved to database, if the column verified_at for this email is null, delete the data/row.
compare the after three days in column like created_at with date now() you can use technique like date time diff to find the range.
Level 2
@tangtang saving the appointment in the database meaning the time is occupied, so another patient cannot take an appointment with the same time of unverified email patient
Level 6
if that's the flow of your apps, that will be make a little problem.
like what this problem will be ?
assume there is a patient using this apps for the first time, off course they need to register email and select date and time they would like to do an appointment (assume you save this in session and this email is verified after).
let's says after one week this patient need to book an appointment again, what would they do ? register the same email again ? verified again ? where they do the login ?
or you have the logic to check if this patient email is ever registered and has been verified, so they can just do an appointment.
the best way to do this verified email is (only if you would like to update the flow of your apps), before patient can make an appointment the email need to be verified first.
so for the first time the only need register the email first, and after that email is verified, they can do an appointment.
this logic is like login before do an appointment. (but only if this flow can be applied with your apps) separate the registration and the appointment process.
Level 2
@tangtang i don't have authentication system, so yes for each appointment you have to enter the email and i verify it.
Level 122
send them the information you need as part of the verification URL, and sign it so that it cannot be tampered with
If you only need email, date and time you can easily add these as a query string. Then when they confirm the email address by clicking the link, they will also be passing you back the date and time they requested.
No, don't use session.
If you feel you must store it server side, create a table for provisional appointments.
I would also be concerned about two people being offered the same appointment because then you have to deal with them both confirming (in either order), so perhaps you should have a 'provisional' appointment which you later confirm by email , but which stops you offering the same time to two people.
Level 2
@Snapey all the problem is about two people wih the same appointment time, and i think that's rarely to happen so i'll just add verified_at field and check it, and for two appointments at the same time i'll redirect the patient to take a new appointment and check the email again :(
Please or to participate in this conversation.