0

I'm running a PHP app with laravel. Should I use a sql lookup for user information everytime or should I just store it in a session/cache after looking it up once and pull it from there? The information will not change often unless a user changes it, so i want to look at it on an efficiency viewpoint.

George
  • 301
  • 3
  • 18
  • Assuming that you are only trying to lookup for the user information for the currently logged in user. Sessions would work just fine. Unless you want to go around and query other user details aswell , sessions are a bad idea and I would stick to a persistent store lookup. – Gayan Hewa Jun 20 '14 at 18:15

2 Answers2

1

If you are talking about about the currently logged in user information then leave it to Laravel. Depending on your configuration Laravel will keep the data and will let you access the data easily using an unified API.

Check Configuration

The authentication configuration file is located at app/config/auth.php, which contains several well documented options for tweaking the behavior of the authentication facilities.

By default, Laravel includes a User model in your app/models directory which may be used with the default Eloquent authentication driver. If your application is not using Eloquent, you may use the database authentication driver which uses the Laravel query builder.

To retrieve a user/user data you may use something like this:

$user = Auth::user();
$userEmail = Auth::user()->email;

Laravel will use session to store the user id and the original data will be stored in the database, so you don't need to worry about the user data. Just check the documentation and let Laravel do it.

The Alpha
  • 143,660
  • 29
  • 287
  • 307
-2

Personally I use the database way. Some people don't know this, but sessions are in fact publicly available. So any data in that session can be red with a session hack.

Now this doesn't happen often (to our knowledge), but it does. And looking up a user by id is not that hard for a database.

Stick with the database fore secure reasons

The database gain is more than the loss of cpu time

Matt
  • 1,081
  • 15
  • 27
  • Unfortunately you are mistaken sir and I wish that was so. Sessions are meant to be red. It does not happen much, but it does. It is also one of the reasons you do not post passwords in your sessions. Cause sessions are vulnerable. – Matt Jun 20 '14 at 17:21
  • As long as you disable ```session.use_trans_id``` and enable ```session.cookie_httponly``` and ```session.use_only_cookies``` it's not trivial to hijack a person's session. Beside, modern frameworks use encrypted cookies so even a guy eavesdropping on your traffic wouldn't be able to get any useful info – ffflabs Jun 20 '14 at 17:26
  • You all just assume server sanity, like so many others. With that being said, database provides (if done right) a more secure manner of getting data. Agree? Cause in the end, that was his question. And the loss in CPU time is acceptable for that safety. Agree? – Matt Jun 20 '14 at 17:33
  • 1
    @Matt Considering many people store session data **in the database**, you're not even making much sense. You can expose your database via SQL injection far more easily than misconfiguring sessions to be publicly accessible. – ceejayoz Jun 20 '14 at 17:34
  • And that is why we encrypt and PDO. http://stackoverflow.com/questions/3224286/what-are-the-risks-of-php-sessions Session are data storages and data storage attracts hacks. Do not just assume a session is safe. Your users data is your lively hood on a website. Protect it however you can. If you are not convinced, not my problem. Go ahead and use your sessions for everything. – Matt Jun 20 '14 at 17:41