Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I'm working on a college project where I have to made a chat that contains invitation options with ACCEPT/REJECT between registered users only. If an invitation is accepted, then open the chat otherwise send a message to the sender.
I've completed the whole project except this invitation option. I know that I can use COOKIE for this (with setInterval), but I need something more secure idea to do this.
In my current PHP invite function, (for example: invitation sender: a#a.com, invitation for: b#b.com) I used to verify the b#b.com user (registered or not) and send back the JSON with verification. If user is registered, then open a chatbox on self-end only (a#a.com) and can send message to b#b.com. The b#b.com user will only gets these message when it opens the chatbox with invitation sender : b#b.com, for: a#a.com.
I have no idea to how to send an invitation directly to b#b.com with option and get back the clicked event (accept/reject) to `a#a.com.
Currently there is a single idea in my mind: cookie with setInterval. But there is a demerit of this idea is, both users page continuously checks the cookie, it means more load on bandwidth and more process on user-end and most of all, it's not secure.
And I'm already user 3 setInterval functions into my project : status check, new msgs check and chat options.
So, can anybody suggest a better approach?
This is rather a broad question, but I'll try to offer some basic design guidance. I expect that a user will enter their email address and the email address of the other person, and click on a "log on" button.
What happens next depends on your design, but this is what I would do. This involves AJAX operations, which is fine for the purpose.
The details are submitted to the server, and a row in a user table is created. The user gets an ordinary session cookie by default, so you just need session_start at the start of each page. A row in a conversations table is also created.
We'll assume that the user is now in a connected but not chatting state.
Using jQuery or similar, a call is made periodically to the server to see if the application status from their side needs updating. To start with, this will determine whether the other user is available. Let's say this call is made every 10 seconds, to avoid excessive load, and every time a call is made, the user table is updated with a last_seen_at timestamp.
You run a script on your server that examines live conversation rows and sees if both parties are online. If they are, and the conversation is not marked as started, then update the row and then notify the users when they next request an update.
When your browser application receives a notification of some kind (in the reply to a periodic AJAX request) it will need to redraw its screen. The life-cycle is: start -> log-on -> waiting -> chat -> log-off. You'll need to work on the JavaScript to do this.
Some of the fields in my suggested table structure below are used to capture the state of the chat, so your PHP application doesn't have to remember things itself. For example if conversation.accepted_by_user_id is null, the conversation is waiting for the second user to accept the chat request. If message.received_at is populated but message.sent_at is null, it means the message needs to be transmitted to the second user when they next send an update request.
Where users or conversations get too old, they can either be marked as stale or deleted entirely.
Side note: we have made no attempt to check that the users own the email addresses they have specified, or whether they even exist. But, for the most part, it doesn't matter - all we need is for the two parties to have a unique string that they can both remember.
Suggested tables:
user (
id (pk) int,
email varchar, // user's email address
email_to varchar, // the email address of who they wish to chat to
session_id varchar,
last_seen_at timestamp
)
conversation (
id (pk) int,
started_by_user_id int, // foreign key
accepted_by_user_id int, // foreign key (null if not yet accepted)
from_notified_at timestamp,
to_notified_at timestamp // timestamp (null if not yet accepted)
)
message (
id (pk),
conversation_id int, // foreign key
is_forward boolean, // true = a->b, false = b->a
message_text varchar, // actual text of message
received_at timestamp, // when it was sent in a server message
sent_at timestamp // when it was picked up in a server message
)
You were worried about the security of cookies. If you use session cookies it means that only the user that initiates a session can use the session ID given to it by PHP (there are a couple of exceptions: the theft of a cookie by a malicious third party via script injection or the capture of data by eavesdropping. You can use SSL and read up on XSS if you are worried about those things, but I would say it is beyond the scope of a college course).
Long story short, you've chosen a non-trivial project! Good luck with it, and if there is something you don't understand, break it down into a smaller pieces, until the pieces are each programming problems.
Now, you can do this project with sockets, but you should learn to walk before you start running. I would suggest you try it this way first (since it is easier but still hard enough) and then if you can do that, move on to sockets.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 1 year ago.
Improve this question
Please how can I make every new user not to have access to another user data in php script, Am already on a live server and whenever a new user registers and enters his dashboard he will be seeing the database of another registered user. The project that am having this issue is an Inventory management system project. Am a newbie can I get detailed instructions on this
This is very very very bad I recommend you shut your site down temporarily and check your code for any leaks as this is not a PHP or Mysql problem it is your script that is incorrect.
If you can't find the problem you can ask me in the comments and I will help you find your problem.
But from what I can read it sounds like one of your SQL queries is not set up correctly.
Also, I saw in the comments the one person is recommending you use a framework I personally code all of my websites is pure PHP as this is what I like and what I feel comfortable with if the framework is needed and you are comfortable using it then yes you can use a framework but honestly coding in pure PHP is not bad you just have to be extra careful in the way you code.
Have a great day and stay safe :)
because you didn't provide enough details about your problem i'll try to outline how a login system works in a concise way. if you don't have any experience writing login system, work with databases or sessions, please study these topics carefully through many articles & videos that exist out there. this topic can't be settled in details in an answer on stackoverflow.
#1 step so, first you need a sign-up page where you collect some data from user, like username, email, phone number, password, etc. then you store this data in database, in a table called users for example. alongside this data you should store a randomly created number like 666187 or an unguessable long string for this user in users table in a field call verification_code (or whatever you like). i'll explain why in the next paragraph.
some parts of this collected data may need verification, email for example, if you did collect the email from user, you'll send an email trying to confirm the entered email truly belongs to the user. your application needs files & codes dedicated to send email whenever you want. after sign-up & storing user data in users table you use your email sending system to email the verification code to the user's entered email (because if user entered an email he/she owns, he/she can access it ). this email contains a link to your application, dedicated to verify users email. (this is not the whole story, but again can't be fit in an answer)
#2 step after completing sign-up page you need the sign-in page. this page contains a form which gets username or email & password of user & checks to find an identical match in users table. if it is found then this is a true user to your application & you should start the session & store user's id in a session variable.
#3 step from now on, on every page which could be accessed only be logged-in users, you fill parts of those pages which is user-specific by retrieving user's id from session & executing queries on database to get data specific to the logged-in user.
a lot of these problems are solved in the start of your project automatically when you use backend frameworks like laravel.
so i suggest you to move toward backend frameworks when you're done with basics & got a good grasp of concepts
maybe it was too generic or vague, i hope you understood something from this answer, sorry if it became long, best regards :)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
At this moment users can create an account at my website (username, password, email)
This wil create an entry in the database which stores the username, the hash of the password and the email adress and will set the level of the user to 0. After this it wil send an email with an url that contains the id of the user and a new hash of the hashed password.
$emailhash = password_hash($passwordHash, PASSWORD_BCRYPT, $options);
$url = "domain/validation.php?id=$id&hash=$emailHash";
At the validation page where the url points to, it wil use the hashed password as password and the hash from the email to check if the user is using an existing email adress.
password_verify(hashedPasswordFromDB, hashOfHashFromEmail);
Is this is a safe way to validate a user or should I add an extra table/column for an extra hash? And what are the pro's/cons of my current method and/or another method? (eg. simpler table...)
EDIT:
In case a user want to change his email adress ( something I'm adding at the moment ), I want to implement the same method (sending an url which contains the id, new email adress and a new hash of the hashed password + the new email adress). In my opinion this looks a bit devious but I don't see another way to change it.
Since we've gotten into this, I'm going to throw in my 2 cents on not just doing this but doing it well.
Most people are suggesting that you add a column or 2 to the user table. That is simple and it works.
But if you want to do this well there are things you want to consider:
Will you also support password reset via email
Will you age out the validation or reset
Can you track someone attempting to compromise an account?
Is there some sort of denial of service or other issue going on?
The best way to do this is to have a separate set of tables related to the user table that capture these type of account events.
Here's a list of typical account events:
Account registration
Account verification
Account suspension
Account deletion
Password reset request
Change email
In a robust system, each of these events, which all have a timestamp, will often have an expiration.
Many of them have an associated hash that needs to be stored and sent in an email.
They all have a "completed" flag to indicate if the implied action was completed.
So a better way of handling this is to have a separate related table to user. For the sake of discussion this table would look something like this:
user_event
-----------
user_event_id (pk)
user_id (fk from user table)
created_on (timestamp)
event_type (registration | verification | password reset, etc)
expires_on (datetime) - manually set as is suitable
token (char40) - sha1
is_complete (tinyint) A boolean to indicate if the action was completed
complete_on (timestamp)
user_ip (ip address of end user)
extra (varchar) : store the new email here. Change to old email when you complete the request.
This is a far more robust way of persisting the data needed for these types of activities within a system, and also has some built in logging. You have an audit trail of activities and can handle or prevent repeated requests.
You also can expire reset requests, and use those expired requests to do an aging activity like sending reminder emails to people who never completed their registration.
You now have a system that supports additional account related features without needing a separate additional table, and you can code new events by just creating a new event_type. Those can just be a string, but you might also want to create a lookup table instead and use that as a foreign key to the user_event table.
Better create a separate token (some hash which is sent in the link as a query), which is stored with a timestamp in the DB. This way you have a link and can check with the timestamp, if the link has expired (compare the timestamp of the token with the current time of the request (when the user opens his link).
I would say: extra hash or any random string in your database. There is no need for sending a password or even a hashed password over the line.
I want to build a simple message system between my users of my website. For that i constructed table for messages as below:
tbl_messages
-pk id int
-fk sender_id int
-fk receiver_id int
-is_read boolean
-send_date datetime
When a user has my site opened in the browser and some other user sends him message, i want to send a notification message to the receiver user (something like 1 new message or (3)Messages) while the page of receiver is opened.
Eg: facebook notification, stackoverflow notification comes when new comment arrives
I performed such action by making a javascript function to be called every 2 min. This function makes an ajax request to output the notification. I wonder is this the correct and effective way to do because i have to perform the sql query every 2 min and if there are lots of records in my table, such action will create more load on database.
What other solutions can I perform instead of this?
If you correctly indexed your database and designed your program, it shouldn't be a problem.
You won't be able to design a notification system as responsive as Facebook and other, since it's almost impossible to create push systems with PHP.
If you have a dedicated/virtualized server (and not shared hosting), look into things such as NodeJS.
I have a simple and generic internal messaging service on one of my PHP/MySQL sites, with a unique messageID, from, to, subject, message, time, and isRead.
In general, what is the best way to check that a user has new mail?
Should I store a simple binary trigger on the main Users table that gets switched to 1 when anyone sends them a message, and then have the user check for that 1 on every pageload, and if there is one, alert them to the new mail (and set it to 0 whenever they go to their Inbox)? But what if it was spam and we deleted it before the user read it?
Or should I store the messageid of the last message the user read, and then do a check for the latest message and see if it's more recent than the last one that he read, and if so alert him? But then how and where should I store this info?
Is there another, more efficient method considering we would have to check for new messages on every pageload?
If the user goes to his Inbox, it should no longer show him that he has "New Mail" for any of the messages that were in his Inbox at the time he checked it, regardless of whether he's actually clicked to read them or not.
Thanks!
EDIT: Some of my users access my site from very basic phones that don't have cookies or even Javascript, so please keep that in mind.
Best way would be push notification from server, like stackoverflow does, using html sockets.
jquery plugin
But keep in mind that is not supported by all browser, so will need to fall back to ajax polling.
About spam i would suggest only notify user after spam checking if done, if possible.
Your solution to store next to user with set bit sounds right, (also you could store number of new message, instead of bit)
In your users table, store the count of new messages, and update when needed.
AJAX polling can be expensive in serverside (the select count(*) from ... can be expensive when your DB became large, and you need to do it, for example, one check per minute).
If the user just browsing in your website, and have no new messages, you can just skip select more information about messages.
We have a back end application to manage messages from our clients. We have 4 customer care executives and we want to prevent the situation where the same message can't be opened by two different members, so we would like to do following...
Suppose user1 opened message id 15 and after that user2 opens same message, so we would like to give a alert that 'This message is already opened by user1'. How do we do it?
Create a different table in your database.
When a user opens a message, update the table to show which message has been opened and by which user.
When another user tries to open it, crosscheck the table to see if there is a row for that message. You can then do the appropriate action such as open or warn the user.
You can delete the rows after a given timeout period to allow others to open.
Schema eg
User_id msg_id time_opened
Unfortunately, you can't use sessions since the sesssion is user specific. However, you can employ flatfiles.
To delete the rows, employ a method such as
$timeout_time_in_seconds = 30;
$time = time() - $timeout_time_in_seconds;
$Query= "delete from table where time_opened
Note that depending on the time field, which can be an int, datetime or timestring, additional date formating of the $time variable may be required. However, int will be most convenient due to ease in comparison and subtraction and no formatting.
I'm mobile so pardon any errors. Also that's why I didn't comment but had to edit. Js issues.
What happens is, when the first user clicks, a quick check and update of the database is made.
When the second user tries, the script will detect the first user has already opened by checking the database.
You can count on this to work if the traffic load is low and the number of users trying to access is not too great. And also counting on the fact that the read and insert queries occur in a short time which as you can Guess is faster then two users clicking at the same time. Unless you have another issue, this should work
Simpliest way would be to implement as pessimistic locking at the DB level
http://www.blackwasp.co.uk/PessimisticLocking.aspx
Whatever language you are using should let you check the DB to see if a row is locked or not and send a message on the screen.
You can additionally setup your application with long polling to notify users when the request resource has become available. http://en.wikipedia.org/wiki/Push_technology