403 Forbidden error in Sessions

[AdrianD]

I'm using F3 with MySQL sessions.

After 30+ minutes of inactivity, when I go to a page that uses sessions I get a 403 Forbidden error:

HTTP 403 (GET /locate)

 D:/Adrian GDrive/00 Dev-server/gridlocatefrontend/fatfree/lib/db/sql/session.php:182 Base->error(403)
• D:/Adrian GDrive/00 Dev-server/gridlocatefrontend/myclassfiles/grid_session.php:18 DB\SQL\Session->__construct(grid_db::__set_state(array()))
• D:/Adrian GDrive/00 Dev-server/gridlocatefrontend/locate.php:27 grid_session->__construct(Base::__set_state(array('hive'=>array(

I understand from other questions that this is due to the session expiring, and that I've not checked for that.  However, I couldn't find examples of code to handle this, and unclear what I need to do, given that the error is occurring when I call " new \DB\SQL\Session($db);", 

Help please.

Thanks

Adrian

[Eric Fernance]

Hi Adrian,

I’ve been having the same issue, but been putting it off as I’ve still got a bit to go before finishing off the code.

So, since no-one else has replied I’ll have a crack at it and one of the more knowledgeable folk can reply if I’m steering you wrong.

PHP >= 5.4 has the session_status method so I guess you could use that (http://php.net/manual/en/function.session-status.php) to check if sessions are enabled and whether or not they are active before calling your new \DB\SQL\Session($db);

Or check isset($_SESSION) for older versions.

Then if it’s not do session_start() before the new \DB\SQL\Session($db);

I haven’t tried this yet though I have to get the same thing sorted out at some point so if there’s a better / correct way to do this I’d love to know as well.

Eric.

--
You received this message because you are subscribed to the Google Groups "Fat-Free Framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to f3-framework...@googlegroups.com.
To post to this group, send email to f3-fra...@googlegroups.com.
Visit this group at http://groups.google.com/group/f3-framework.
For more options, visit https://groups.google.com/d/optout.

[bcosca]

session_start();

$f3->set('JAR.expire',time()+86400); // extend the session duration by 24 hours

[xfra35]

@AdrianD, the SQL Session class throws a 403 error when your IP change. Is that what happened?

[AdrianD]

Thanks for the feedback.  To answer some questions:

1.) Extending the session duration by 24hr won't solve my problem.  People visiting the site might not use the site for 7 days or longer.  To confirm, if they've visited before (session/cookie) , they'll get the 403 error when they next return, hours, days or weeks later.

2.) I've checked and confirmed it's not an IP issue.  My IP remains the same during the issue.

I'll follow Eric's advice, and report back,  but any additional advice is welcome.

Adrian

[xfra35]

The second reason why a 403 would be thrown is that your browser has sent a different user-agent (or forgot to send it). See here.

It could be a browser issue. Can you check that your browser is sending consistently the same user-agent string?

[AdrianD]

Thanks for the suggestion.  From 30 users, 11 people have experienced this, but I will try to capture user-agent so that we can check this.

However, the fact that it occurs for so many people, means I'll still need a solution to identify, trap and properly respond.

As before, as soon as they page-refresh, it works fine.

Adrian

[AdrianD]

Hello

The Forbidden HTTP 403 is still occurring.  Please help.

I followed Eric's advice and added the following check to my code: 

if (session_status() !== PHP_SESSION_ACTIVE)

          new \DB\SQL\Session($db);

When I tried to load the page this morning, I received the HTTP 403 error.  It's errored when initiating the call " new \DB\SQL\Session($db);", and reports an error at 

• D:/Adrian GDrive/00 Dev-server/gridlocatefrontend/fatfree/lib/db/sql/session.php:182 Base->error(403)

The error page shows 'SESSION'=>NULL.  The user-agent is the same as yesterday: "Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.90 Safari/537.36"

The cookie file gave me a PHPSESSID, which I checked in the SQL SESSION table.  It doesn't exist.

When I refresh page, the page loads successfully, and a session entry with the same PHPSESSID has now been added to the SQL SESSION table.

So the scenario appears to be when the cookie contains a PHPSESSID which doesn't exist in the Session table.  Is there code I need to add, or should this be handled as part of the new \DB\SQL\Session call.

Thanks in advance for your help

Adrian

[xfra35]

Tricky issue!

Well first of all, you can remove the check for PHP_SESSION_ACTIVE. If your code is structured properly, there is no reason for the session to be started before your call to DB\SQL\Session.

Secondly, you wrote that you could not find in db the session id corresponding to the cookie, but that's because the framework destroys the suspect session just before throwing the 403 error.

So it really looks as if your session was present in DB but was discarded as "suspect" because either your IP or your User-Agent has changed since yesterday.

You wrote in the first place that your IP doesn't change. How are you so sure about it? You need to check today's IP with the one you had yesterday (you can get that info from the web server logs).

[ikkez]

it feels like this Session Hijacking protection is causing more problems than it solves.

[AdrianD]

Thanks again for the feedback.  I'm going to test over the next few days, and see if there are differences in the user-agent.

It's unlikely to be the IP address, as the error is occurring on localhost (as well as live server),  and the localhost IP (::1) remains consistent.

Thanks

Adrian

[AM]

Hi, did you find a solution for this problem as I also get this error message in multiple projects.

[ved]

The session handlers included in F3 (\Session and \db\*\Session) reply with 403 forbidden when a "suspicious" session is detected.

This usually means the ip or user agent has changed between requests.

You can use the $onsuspect callback to override the 403 and do what you wish on those cases. See https://fatfreeframework.com/3.6/session