I'm writing an MVC web application which requires people to login. I want the logged in people to be stored in a database and wondered what the best way of doing this was.
So far I've stored the users session ID and user ID in a table called LoggedOn. Then I can determine if a person is logged on by checking if their sessionID exists in the LoggedOn table.
Is this the best way to do is or is there a better way?
I would store the id and the timestamp of the last action, and delete them if the timestamp is older than a certain amount of minutes, or if they log out.
Related
I am a newbie of the CI framework. I am trying to understand what session id is for. Here is the description from CI doc:
The user's unique Session ID (this is a statistically random string with very strong entropy, hashed with MD5 for portability, and regenerated (by default) every five minutes)
I am just wondering under what occasions I should use this.
Thanks
The session ID in CodeIgniter is essentially either;
if using a database for session storage: a random hash (string) that references the session data in the database so CodeIgniter knows what data belongs to who
if not using a database; an encrypted set of data that CodeIgniter uses (that you can leverage as well) to track the user (eg. if logged in, a user ID)
I'm building off of a previous discussion I had with Jon Skeet.
The gist of my scenario is as follows:
Client application has the ability to create new 'PlaylistItem' objects which need to be persisted in a database.
Use case requires the PlaylistItem to be created in such a way that the client does not have to wait on a response from the server before displaying the PlaylistItem.
Client generates a UUID for PlaylistItem, shows the PlaylistItem in the client and then issue a save command to the server.
At this point, I understand that it would be bad practice to use the UUID generated by the client as the object's PK in my database. The reason for this is that a malicious user could modify the generated UUID and force PK collisions on my DB.
To mitigate any damages which would be incurred from forcing a PK collision on PlaylistItem, I chose to define the PK as a composite of two IDs - the client-generated UUID and a server-generated GUID. The server-generated GUID is the PlaylistItem's Playlist's ID.
Now, I have been using this solution for a while, but I don't understand why/believe my solution is any better than simply trusting the client ID. If the user is able to force a PK collison with another user's PlaylistItem objects then I think I should assume they could also provide that user's PlaylistId. They could still force collisons.
So... yeah. What's the proper way of doing something like this? Allow the client to create a UUID, server gives a thumbs up/down when successfully saved. If a collision is found, revert the client changes and notify of collison detected?
You can trust a client generated UUID or similar global unique identifier on the server. Just do it sensibly.
Most of your tables/collections will also hold a userId or be able to associate themselves with a userId through a FK.
If you're doing an insert and a malicious user uses an existing key then the insert will fail because the record/document already exists.
If you're doing an update then you should validate that the logged in user owns that record or is authorized (e.g. admin user) to update it. If pure ownership is being enforced (i.e. no admin user scenario) then your where clause in locating the record/document would include both the Id and the userId. Now technically the userId is redundant in the where clause because the Id will uniquely find one record/document. However adding the userId makes sure the record belongs to the user that's doing the update and not the malicious user.
I'm assuming that there's an encrypted token or session of some sort that the server is decrypting to ascertain the userId and that this is not supplied by the client otherwise that's obviously not safe.
A nice solution would be the following: To quote Sam Newman's "Building Microservices":
The calling system would POST a BatchRequest, perhaps passing in a
location where a file can be placed with all the data. The Customer
service would return a HTTP 202 response code, indicating that the
request was accepted, but has not yet been processed. The calling
system could then poll the resource waiting until it retrieves a 201
Created indicating that the request has been fulfilled
So in your case, you could POST to server but immediately get a response like "I will save the PlaylistItem and I promise its Id will be this one". Client (and user) can then continue while the server (maybe not even the API, but some background processor that got a message from the API) takes its time to process, validate and do other, possibly heavy logic until it saves the entity. As previously stated, API can provide a GET endpoint for the status of that request, and the client can poll it and act accordingly in case of an error.
I am assuming I cannot do this using sessions but rather the DATABASE. So the user would sign in, it would set their TIMESTAMP and I display that from the database. Then it becomes deleted when the user logs out or their session is terminated. How would the code look for this?
The better question is, is my logic correct? Would this work? Does this make sense?
By default application servers store session data in temporary files on the server.
By storing session data in a database table you are able to create an interface that will show information about the users that are logged in. Apart from that, using this (database) approach is a serious advantage if you need to scale your application by adding more than one server.
One of the most popular ways to implement such a functionality is to create a session table containing your users' session data. This may look like:
create table session (
id number primary key,
data varchar(240),
timestamp date
);
The data column stores all the session data in a serialized form this is deserialized each time a user requests the data.
Serialization and deserialization may have inbuilt support depending on the platform you are using. For example, if you are using PHP, the functions session_encode and session_decode may be found useful.
You can't find out when a user logs out in PHP and the Javascript workarounds are a bit far from a stable solution.
A couple of things you need to do: Create a column in your user table called last_activity and update their last_activity to the current time whenever a user loads a page.
For a list of who's online, query the db for users with last_activity values more recent than 10 or 20 or whatever minutes ago.
To update the last_activity column use:
UPDATE users SET last_activity=CURRENT_TIMESTAMP() WHERE id=2
For a list of users online
SELECT * FROM users where last_activity >= (CURRENT_TIMESTAMP()-(60*20))
In my application I have an administrator who can create Tournament objects. When the object is created the service also creates a user (based on the tournament director's info which was entered at creation). The username for the user is the director's e-mail, the password is randomly generated and then mailed to the director.
When the director logs on with his e-mail address and password, I need to be able to link him to his own tournament, in order to only allow him to edit his own tournament's details. I have tried to find a way to store the TournamentId in the default ASP Net Users database, but was unsuccessful.
I had a look at this SO question which would certainly help me, but I can't figure out how it would apply to my problem. When the user logs on, I can't put the TournamentId in the userdata seeing as I don't know it.
Should I then do a lookup in the Tournament table to see which ID corresponds to the email address entered at login and store that in the userData? It seems quite unelegant this way.
I guess you should have a CreatedBy column in your Tournament table where you store the ID of the user who created the tournament. Then when the user logged in, get his id ( may be from session ,if you store it there), Do a select query where CreatedBy=loggedInUserId .That should do the trick.
this may be a easy question, but I really need a light to go on.
I have this huge PHP system in codeigniter, and I'm using the library Quick Auth, and I need let users log on only at one computer/browser at a given time. So if Jake logs on In PC1, then Jakes tries to log on in PC2, PC1 session get invalidated and closed.
I was trying to manually search in the ci_sessions database table to try to eliminate the other user session, but seems like too pain. I want to know if there's one simple solution, I have no problem extending session, but I need more like an advice.
Thanks in advance
You will have to modify either the table indexes or session library code to limit one user to a single session. This can be done by:
Adding a unique index for the username (or ID) and the cookie/session ID
Modifying the library code to INSERT OR REPLACE based on the user/cookie