Alot of my controllers have functions that look like this. What is the best measure to take with CI when a session runs out and a function like such is called?
$this->foo_model->create_bar($this->session->userdata('userid'), $bookId);
I don't fully get your question maybe, but when you call $this->session->userdata('something') for an expired session it will simply return FALSE.
So, the best method would be checking if the variable isn't FALSE? As you would do with any other variable that might not be the value you want:
if($this->session->userdata('userid')){}
//or check it into the model's method, wherever you prefer
Where and when to do that strongly depends on your design. If you always need to do the same check you might want to make it a library or a model's function, so that you just need to write your code once and just call that method. If you need it done before anything else you might consider placing it in the constructor, or as #Jordan Arsenault suggested, create a parent MY_Controller which does the check, and all your regular controllers extends it. Really, this depends on you architecture and you didn't provide enough info to answer that.
All I can say is make your methods fault tolerants, always check for the correct value before feeding the rest of your code (if an expired session breaks your workflow)
You can use cookies to revive an expired session.For example you can create a token for users when they login to your application .This token has a related userid that your application knows globally then save a cookie on the user machine that contains the token.each time the session expires ask for the client cookies and see if this cookie is available then with its userid re-create the session.if there's no token available redirect your user to a page telling him what has happened and ask him to login again.
When the user logs out delete the token and the cookie
Related
I use the session value to check the current language, but we I logout, all sessions values are cleared and the language changed to default. does any way to keep the session unclear after logout.
Using session for storing the language is not a good option ( truth is its worst).
What to use then ?
You should either use the cookies as language is not important or secret data (I think so). Even if the user somehow loses the language he selected, he could select it again and all that will be stored in cookie for as long as you want. To know more about cookies in Yii click here
BUT IF
You for some reason hate cookies(although I will recommend cookies only) then
the second option is appending the language with the url in every request like ?lang=en. This might be a tricky one as you will have to take care of this parameter in every request and url.
How to keep current language after user logs out ?
You can use setComponent() method to set, application components dynamically.
Try by creating a method, say:
public function setLanguage(){
// When User log in is success, raise a flag, and set in by:
// Or more specifically, donot copy and paste it, at least give some research and do it something like this.
Yii::app()->setComponent('language','en');
}
And use it, by Yii::app()->language;
So, you can here dynamically set and reset your language component.
As Let me see said, using session for language is not a good option.
I think this will work not much sure .
Use Yii::app()->user->logout(false). It will only remove the authentication related information from session and keep the other data there intact.
Many websites I've created have user data stored in sessions for quick access. The problem is that if an Administrator chooses to delete or disable a user's account, as long as they have their session cookies they're still technically "logged in."
While there are a few workaround solutions, such as making a database check on the user before they make any changes or adding a database check into the logged in verification function, these are less efficient than I would like.
So my question is, is there a way to close a session for a user from another user based on data stored in said session, like a user ID? If not, when would it be considered insecure to use session data internally, without database verification?
I should note that this question is asked under the assumption that I will be using the built-in $_SESSION variable, not some sort of custom database implementation, since a database session would be fairly easy to track down.
I'm trying to avoid using a database since keeping session data on the local server is far more efficient than adding the latency of connecting to an external database every time I want to access session data.
Try using the following achieve what you are looking for:
Getting all the sesssions: $_SESSION List in PHP
How to kill a particular session: How to destroy a specific PHP session
Have you tried session_destroy?
Session Destory
You can use session_destroy at the end of the process, but furthermore:
In order to kill the session altogether, like to log the user out, the session id must also be unset [and] then the session cookie must be deleted.
As a side note: one 'good' thing about PHP documentation is you're absolutely, like, guaranteed a laugh.
You can't destroy session on someone else his computer... . If you really want to do it, you should check on every page if the account is still available.. Or some other workaround.. .
Just looking for some ideas and maybe feedback on what I have at the moment.
A website that has standard access using a generated 'session id' stored as a PHP
session. This is alwazs passed as a GET method and checks if the user has been active for the last 10 minutes.
Otherwise unset and log out.
Problem I have if a mobile application accesses the same information in a similar manner... is it best to use the session id's ... as it can become annoying if suddenly your session runs out in a mobile app, esp. if the app has been left open.
So I thought of using a dev key. What is the best way to use a dev key for third party access? Is it to simply override the session key - i.e constant log in? or is it maybe best to use both?
Thanks in advance
I wouldn't suggest using a GET parameter to maintain sessions. It can leave you vulnerable to attacks. If you really want to do it make sure you generate the session IDs randomly. But whenever I want sessions I use PHP's built in session functions
You would manage a distributed session using db. You create the same session data on a table, then, the differents clients can ask to the db if exists a session open. You can try that using different status from the session.
In that way, you can use the table to persist the session data, but use the built in php sessions functions, like #Adam Lynch says
At the moment my CMS creates a PHP session for every user who visits the site. I'm thinking about only creating a session for users who want to log in. The problem I have here is that some UI elements for logged in users are on all pages, so on every page request the system has to check if the user is logged in, which means I have no other option to start a session on every page request? Or am I wrong? Is it normal practise to create a session for every user, even if dose not want to log in?
Short, I'd like to know if A. there is an option in my use case to only create a PHP session for users who want to log in and B. if it consider bad practise creating a session for every user, regardless if he wants to log in or not. If this isn't the case, I can leave things as they are really ...
You have no (real) choice. You can not know, that a user is logged in (or not) without a session.
Quick answer:
In your use case, it is perfectly fine to create a session for every user. Sessions are negligible and not something to worry about as far as performance goes (in your case).
The method you're using is not bad practice at all. In fact I'd say it's pretty near best practice.
Long answer:
In my 6+ years of experience as a PHP programmer in the corporate world, it is perfectly normal to create a session for every user, regardless of whether or not they're logged in. In fact, sessions can be used to do a lot of convenient features for a user even when they're not logged in -- such as shopping carts, etc. You're doing things right. If you want to speed up performance at all, use a tool like Google's Pagespeed and Yahoo's YSlow -- they'll give you tips on best practice for websites.
It is possible to avoid creating a session every time. So what if session files are small? Why proliferate them when it's unnecessary?
This is what I do, in essence:
Check for the existence of the session cookie on the incoming request, and only do the session_start() if you've received one.
Logged-out users browsing the site (typically) won't be sending the session cookie, and so they won't trigger a session_start(). Simple.
Once someone logs into your site and you do want to start a session (session both logically in your application and in the PHP sense) then use session_start() etc which will handle setting up the cookie.
And once someone logs out, make sure you destroy the session cookie too, not just the PHP session itself.
Obviously the user could block your cookie operations at their end and screw things up, but they could do this anyway.
Can't you just look for an empty $_SESSION value to see if they're logged in?
In most cases, logins are managed via the session, therefore you must create a session at the start of the page to determine if they are logged in or not. You have no choice really... It is not bad practise, it is common practise.
This may be a bit of daft question, but I don't come from an OOP background and although I'm reading and learning as I go I'm still struggling with a few concepts.
Right now I'm working with PHP 5.3 and desiging a fairly simple login using a few different object classes: User which defines the user. Session which starts and maintains session data and if someone is logged in, and Database which does the queries.
So when my script is run, my session object is instantiated, etc... here's my problem though. When I move from one page to the next how is that object tracked? Or perhaps rather my question is how does PHP know the objects that relate to my login are mine and not someone else who logged into the site?
I know if I'm doing this in a non OOP way, I'd simply check the session cookie on each page and check my data that way, which is fine my brain can handle that. But, where and how is object data tracked.
EG:
On each page I want to check if someone is logged in I reference $session->is_logged_in() etc is_logged_in checks the a private variable name is true or false.
There's no checking of cookies at this point which means this object still exists, and, as it keeps asking for a stored variable the instance must persist to be useful... but how does PHP, the server, whatever tie that instance of that object to that user? If all of these objects float around on the server till I destroy them won't there be lots of memory used by objects?
As I said at the start it's probably a really basic, fundatmental question but I'm yet to have my eureka moment with this, I might go back to simpler PHP.
Session data (that is all the data in $_SESSION) is by default serialized and stored to file between requests. The data gets unserialized automatically when session_start() is called.
From the PHP manual on Session Handling (emphasis mine):
The session support allows you to register arbitrary numbers of variables to be preserved across requests. When a visitor accesses your site, PHP will check automatically (if session.auto_start is set to 1) or on your request (explicitly through session_start() or implicitly through session_register()) whether a specific session id has been sent with the request. If this is the case, the prior saved environment is recreated.
Nothing is persisted in memory between requests. PHP has a shared nothing architecture, meaning all objects are recreated on each request anew, unless you are using dedicated cache mechanisms.
So when my script is run, my session object is instantiated, etc... here's my problem
though. When I move from one page to the next how is that object tracked? Or perhaps rather
my question is how does PHP know the objects that relate to my login are mine and not
someone else who logged into the site?
When you start a session, an id is generated. All the session data is associated with that id and it is given to the browser to store in a cookie. Subsequent requests include that id in the cookie, and PHP pulls the data out from where it has stored it.
If all of these objects float around on the server till I destroy them won't there be lots of memory used by objects?
The objects are serialized to files rather than being held in RAM, and are cleaned up with the session expires.
I find that sometimes, when I start to lose perspective as to whats really "happening", a quick trip to a page with phpinfo();,or just logging some ENV variables often clears things up, and puts me back on track…
Globals let you see exactly what "exists" in your environment, and allow you to take a mental restocking of what you're "working with", and how to best attack the challenge.. You'll find a wealth of information, and as to your specific "issues" there are such entries as…
$_SERVER["HTTP_COOKIE"]
$_SERVER["QUERY_STRING"]
$_SERVER["argv | c"]
$include_path
etc…
also, it never hurts to read through your /etc/php.ini (wherever the case may be) for a little one-on-one-time with PHP's internals - to remind you "what its all about".