I'm having a big trouble here: In my company we have a huge system and too many people access it every day. We are having the following problem:
User access his account on the pc A.
He goes to write his text
He write all his text but doesn't save it. Then open a new tab.
In the new tab, he access the account of his customer.
Using the account of his customer, he goes to write the customer's text.
After type the customer's text, he goes to the previous tab to save his own text and after save the customer text.
The two texts appears on the customer's page.
I was thinking in a way of the current screen store somewhere the actual session id, and then when the user click in a link, or post a form, the current page send the session id loaded when it was rendered to the requested page.
Can you help me please?
Thanks!
Its a little difficult to follow the use case specified, but it sounds like you need to check access rights to save 'text' to a particular account.
at the moment it appears that your authenticated customer account is saving to an account that isnt theirs?
for eg, in the new text method, before anything happens:
if($currentUserID != $accountOwnerID)
{
// throw a 403 exception here
}
this way if they happen to change identity during a session, their access rights will always be checked before anything else can happen.
The best solution is to use named sessions. See: session_name()
By using it, you can have different (and isolated) sessions which will not conflict to each other, even if in the same computer, same browser.
For your particular case, I would create a session named after the user logon, which is unique. That way, if user A logs in, he will have his own session. If a new tab is opened, and he logs as user B, a different session will be created, and both tabs will work simultaneously and correctly, each on it's own session space.
Just add session_name($UserLogon); before session_start(), should work good.
You can use session keys to check.
For that first you need to create a random session key and store it in a session variable. Also provide this value as a hidden element in your form. During the insertion you can check whether the value in hidden element is same as the session key, then insert. Else through error message. After successful insertion reset the session key again. It will overcome your problem.
Hope it helps.
Related
I made a php script that acts as a to-do list. On the admin side (just admin.php), there is a display table, and this table fetches each record from the to-do list table in mysql, then places a remove button next to each record.
Every remove button has an anchor tag with an ID based on the specific associated row from mysql. So when someone clicks the remove button, the url goes to /remove.php?id=ROWID
The issue is that someone could enter that url from any page with the proper rowid, they could delete the data. On the remove.php, I am using the $_GET method, to get that ROWID. I could make a form and have that POST, which I have for other functions on the site. But even for those, if someone types in add.php, they could still access the add functions within the php script.
I tried starting a session using session_start(); in the admin.php page (which will eventually be locked to only authenticated users who have admin rights), but if someone knows the link, they are still able to go to /remove.php?id=ROWID even without being in the session, or stating a session from admin.php
Am I missing something? Is there a way to prevent access to remove.php expect for users who are authenticated or within the session?
Thanks to the above post,
I used:
if (isset($_SESSION['ID'])){
code goes here for if they are authenticated
}else{
die("You're not logged in as admin");
}
This will start a session on page1.php and on page2.php will check if a session was started from page1. If not, the error (die) message will be displayed.
If you want to expire the user’s session based on some length of time, use this example:
http://thisinterestsme.com/expire-php-sessions/
Have a session problem with application when opened in multiple tabs of a browser.
In my project a user can have multiple log in id's so he could log into the app with two id's
at the same time as two diferent users. but when they try to log in with two id in multiple
tabs of a browser. the same session of the browser is being shared and the data gets messed up.
Any insights to solve this issue?
I see a pattern in mail.yahoo.com , if i log into my mail.yahoo with one user id and try to login in
to other user id in the new tab. one of them logs out. Any idea how this could be done...
Thanks
Piecing this together from against other answers it sounds like you need multiple application streams.
That is, you have a situation where you need multiple "users" to be logged in to the application on different tabs on the same browser, same machine.
This isn't because they are different people using the machine, but rather the same person working with different personas.
It turns out, I've implemented something similar in the past myself, in order for managers to be able to "ghost" through a system as their staff members. They log in as the other user, but in a read only mode so they can see what's going on.
OK. So how to do it.
Put simply - the session isn't enough - you need more than that. The session ID is stored in a cookie on the client machine and there isn't really much you can do about the set-up - one browser = one session.
However, what you can do is split that session up with an application stream, or application context.
That is, don't store anything in the root of your session - split your session into distinct components into which you have a set-up identical to your current session.
The key for each session is then the "application stream" key. You need to pass this around in your URLs.
E.g.
Your current session may have a simple set-up:
$_SESSION['user'] = 'some username';
$_SESSION['role'] = 'power user';
Instead you store that as:
$_SESSION[0]['user'] = 'some username';
$_SESSION[0]['role'] = 'power user';
On all urls you add:
&appId=0
And whenever you reference your session you use something like:
$username = $_SESSION[ $_GET['appId'] ]['user'];
Obviously, you wrap all this up in a nice session handling class, but that's the basic idea.
If you want a link that generates a new login page with a new application stream, you simply change the appId on the link (or completely omit it and trap that in your login code).
E.g.
$sLoginLink = "<a href='/login.php?appId=" . generateNewAppStreamId() . "' target='_BLANK'>New Login Screen</a>";
As everything is still stored in the session, the whole of your application should work exactly the same - just as long as you always have the appId on every URL in the system.
I've tried to make the explanation as simple as possible - forgive me if I've used too many words.
If you want to use session then you must arrange such mechanism that only one user can be logged in same browser. At login page, check availability of session and it is already have a value than redirect your page to any logged in page like home, profile or whatever you have.
When the user logs out or logs in using a different user ID you must use session_regenerate_id() to force PHP use a different cookie for the new login.
This is actually the best practice on logout.
If you want to have two users logged in simultaneously from the same browser you have to put something in the URL to tell them apart. For example, after login, user #1 will see all the pages as http://www.example.org/1/... and user #2 will have its own customized URL (http://www.example.org/2/...). Then you need to use session_set_cookie_params() for each user with the correct value for parameter $path ('/1' for user #1, '/2' for user #2 and so on).
It's not recommended to use the user ID as customized user directory but to generate a hash from it.
i have this question. My website is build whereby a user can only be in the member's page if he has login. therefore every page has this,
if (!$_SESSION['userid']) header index.php
Problem is that if i ban the user and the user did not end the session, he will still be allowed to use the site until he end the session and try to login again, and he will be denied due to the change in the status in the database.
I'm thinking that the only way is to delete the physical session file in the server, but i dont know how. Anyone?
What I have done is create a database query in a header file that is included in every page that either pulls the users profile or checks to see if they were banned. If so then I destroy their session.
What you need to do is add in your ajax post the user id, or some other information to identify the specific user posting. This way you can check on the server side if the user is allowed to post with each post, and if not take the necessary action.
Unless you're using the multi-level directory save method, something like this would probably be enough:
unlink(ini_get('session.save_path') . 'sess_' . $bannedSessionID));
check that your server's session files have the 'sess_' prefix, though. It could possibly be overridden somewhere. But in any case, by default all the session files are in a single directory (/tmp unless they've been moved) and can be opened/read/written/deleted by the webserver (as they have to be)
I want to export an Excel table with PHP. That table contains links to the actual website.
The problem is that these links can only be seen by an authenticated user.
When I click the links in the Excel file, even if I've logged in to my website (so technically there is a session already started), the page won't open, but instead redirects me to the login screen (so it starts another session).
Any solutions?
What you will probably want to do is to create a unique identifier for the user. This key would be appended to the end of the URL. When the user clicks on the URL in the file, the key would then log them into the site on the specific page they clicked on.
The generated URL would look something like this:
http://www.mysite.com/linkedpage.php?SK=asdsomerandomstring123
If they need to be saved, then the session values will need to be saved in the database either in a serialized array or individually.
There are inherent security issues with allowing login based on a key in the URL, so you will need to weigh the convenience of what you are trying to do against any security issues that will come with it.
This question is bogus :)
There must be a bug in my app, because the session info is being kept when I click the link in excel.
how do you check if a user already has logged in?
so that if a user in another browser cant log in with the same account.
also, is this a good solution or should i let the user log in in the other browser and then log out the current user and display a message (you are logged in from another location) just like messenger does?
Using sessions is a good way to do this, and is a very common method for controlling authentication.
The flow usually looks something like this:
User visits site, and session_start() is called. A unique session identifier is set for that visitor (ie. a cookie).
User submits his login credentials to a login form
Login credentials are verified, and this fact is stored in the session data with $_SESSION['logged_in'] = true, or something similar
For the rest of the user's time on the site, you can check $_SESSION['logged_in'] to see if the user has logged in.
In order to control a user's logins, you could simply have a field in a database (users table is fine) indicating what the current session id is (retrieved with session_id()) for the user, and if it doesn't match the cookie value you just received, then you immediately call session_destroy() for that id, and consider the user as logged out.
Using $_SESSION means you don't have to worry about generating your own tokens, and gives you the power of the built-in superglobals to facilitate storing information about the user's authentication status.
Personally, I would allow multiple sessions to be active for a user for most web sites, as there's usually not a good reason not to, but it obviously depends on the nature of the site. However, storing the current active session id as mentioned above is a pretty simple way to accomplish this.
Generate a random token upon signing in (or use the sessionid), and store this in the database and in the users cookie. With each page access, ensure that the users token matches the database entry. If the two don't match, alert the user that they've logged in elsewhere.
You could also store the login time, which subsequently would be the time the token was assigned, and require 30 minutes before permitting another user to login with the same ID.
The first half of the question was answered well with how to detect the multiple users but how to treat them I think still needs a bit of work.
First if a user logs in correctly let them in, don't prevent them if they are logged on some other place. If you really don't want the user to have two open sessions then log out the old one or simply update the session id that you are saving so you can bounce out the old connection. You can inform if you want but I would only message the session that you invalidated. If you message the user logging in it becomes annoying when you are only dealing with the case of a user switching computers and they forgot to log out of the old session.
Well All solutions mentioned above will work but if on every page access you are making a call to database and checking for the session token to see weather its the same token assigned to user .. will kill your response time. what i'll suggest is use a caching mechanism instead of database in above said solutions. storing session token into database will add extra field to your database which is actually not required. Use open source caching solution like memcache.
you can make a table like userLoginStatus with fields like clockIn time & clockOut time,
and insert current time in clockIn when user is do login, leave clockOut time blank at that time, it should be updated only when user do clock over logout button,
so you can check specific user's current status, where clockOut is empty that user should be logged in. because it updated only when user do logout.