session issue (403 error)

[v.]

Hi,

I am trying to use the f3-access library and I am getting some weird results with it.

I have a controller class that is being extended by all my other controllers (1 controller to rule them all).

In this controller I have the following code:

function beforeroute() {
        $access=Access::instance();
        $access->policy('allow'); // allow access to all routes by default
        $access->deny('/admin*');
        // admin routes
        $access->allow('/admin*','100'); //100 = admin ; 10 = superuser ; 1 = user
        $access->deny('/user*');
        // user login routes
        $access->allow('/user*','100'); //100 = admin ; 10 = superuser ; 1 = user
        $access->allow('/user*','10'); //100 = admin ; 10 = superuser ; 1 = user
        $access->allow('/user*','1'); //100 = admin ; 10 = superuser ; 1 = user
        $access->authorize($this->f3->get('SESSION.user_type'));
        $layout=new LayoutController();
        $this->f3->set('layout.side_menu',$layout->LayoutMenus());
}

I think this is self-explanatory: all visitors can access everything, then admin routes are denied to anyone without admin access (session.user_type=100),

Then user routes are denied accepted for logged in users (user_type=1). Super users are not really used for now.

Is this the correct way to handle this?

It seems to be working quite well but the issue I am running into is that on a page refresh with ctrl+f5 this will sometimes return a 403 (never on f5 refresh though). This happens on the index page which should always be accessible to anyone.

Sometimes it happens every other time, at other times I need to refresh with ctrl+f5 at least 5 times before the 403 is returned. This happens wether a user is logged in or not.

I am using cache, could this be interfering with this?

Sometimes after trying to figure this out and changing caching options and access options the problem will not pop up at all, so it is hard to reproduce at times, but when it starts occuring it seems to be occuring often.

[JoséRené Barnéond]

CTRL+F5 used to refresh cache and everything, nowdays i'm not so sure... i'd go and check if the PHPSESSID changed, that would mean the session.user_type will not have been set and that could throw the error... maybe? 

i noob zorry

José René Barnéond

--
-- You've received this message because you are subscribed to the Google Groups group. To post to this group, send an email to f3-fra...@googlegroups.com. To unsubscribe from this group, send an email to f3-framework...@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/f3-framework?hl=en
---
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 https://groups.google.com/group/f3-framework.
To view this discussion on the web visit https://groups.google.com/d/msgid/f3-framework/1cddef89-5f96-49a4-b45f-f432022dbe2b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ved]

Hi,

Try using a callback function on the authorize method. Maybe you can get some more info about why that is happening.

Also, if you're using any of F3's session handlers, note that they can also throw an http 403 status when your ip or user agent changes between requests.

So, if you're testing your website and change user agent (for example, by activating your browser's developer tools/responsive views/etc), or your ip changes, then F3 session's handlers will show you a 403. You can use the onsuspect event to handle or alter this behavior.

[xfra35]

To follow up on @JoséRené and @ved's posts: we need to find out who is throwing the 403 error (f3-access, the session library, a caching proxy...) . If you're looking at the PHP error log, you should get a clue.

Also you wrote :

I am using cache, could this be interfering with this? 

What kind of cache? What is stored in cache?

--

BTW the permissions of the user routes can be shortened in 1 line:

$access->allow('/user*',['100','10','1']); //100 = admin ; 10 = superuser ; 1 = user

[v.]

The cache does not seem the problem. I have disabled it entirely and there does not appear to be a difference.

I did not look at the error logs, which obviously I should have done first (so sorry!).

It seems to indicate a problem with the session:

[Thu Jul 05 16:26:54.566323 2018] [:error] [pid 13651:tid 139994240866048] [client <-myip6address->] FastCGI: server "/tmp/fpmuser-vd7784" stderr: PHP message: HTTP 403 (GET /)
[Thu Jul 05 16:26:54.566349 2018] [:error] [pid 13651:tid 139994240866048] [client <-myip6address->] FastCGI: server "/tmp/fpmuser-vd7784" stderr: PHP message: [lib/session.php:76] Base->error()
[Thu Jul 05 16:26:54.566352 2018] [:error] [pid 13651:tid 139994240866048] [client <-myip6address->] FastCGI: server "/tmp/fpmuser-vd7784" stderr: PHP message: [lib/base.php:259] session_start()
[Thu Jul 05 16:26:54.566355 2018] [:error] [pid 13651:tid 139994240866048] [client <-myip6address->] FastCGI: server "/tmp/fpmuser-vd7784" stderr: PHP message: [lib/base.php:515] Base->ref()
[Thu Jul 05 16:26:54.566357 2018] [:error] [pid 13651:tid 139994240866048] [client <-myip6address->] FastCGI: server "/tmp/fpmuser-vd7784" stderr: PHP message: [app/controllers/Controller.php:14] Base->copy()
[Thu Jul 05 16:26:54.566360 2018] [:error] [pid 13651:tid 139994240866048] [client <-myip6address->] FastCGI: server "/tmp/fpmuser-vd7784" stderr: PHP message: [lib/base.php:1788] Controller->beforeroute()
[Thu Jul 05 16:26:54.566362 2018] [:error] [pid 13651:tid 139994240866048] [client <-myip6address->] FastCGI: server "/tmp/fpmuser-vd7784" stderr: PHP message: [lib/base.php:1612] Base->call()
[Thu Jul 05 16:26:54.566365 2018] [:error] [pid 13651:tid 139994240866048] [client <-myip6address->] FastCGI: server "/tmp/fpmuser-vd7784" stderr: PHP message: [index.php:68] Base->run()

Line 14 of my controller sets a session csrf token.

If I disable it I get the same error on line 39 which is then the first line in my before route to use a session variable.

Even if I disable the csrf session thing and modify the authorize line:

$access->authorize($this->f3->get('SESSION.user_type'));

to

$access->authorize($this->f3->exists('SESSION.user_type') ? $this->f3->get('SESSION.user_type') : 0 );

it shows the same problem.

Again: the problem only occurs on ctrl+F5 and never on F5 refresh.

Edit: I did experience a few events (after 7000 tries or so) with the same thing after a standard F5 refresh.

When the problems happens the user is also logged out.

[ved]

Are you using F3's Session class?

Because AFAIK, that class is the "Cache based session handler", so you really need the cache to be enabled in order for F3 to save session data in the configured cache backend. (which can be regular files, APC, memcached or, redis). 

I'm not exactly sure what happens when trying to use the session class without cache enabled.

If you are using the Session class, you can try commenting it out completely and just use $f3->set('SESSION.something') and $f3->get('SESSION.something') directly without initializing the Session class and see if the issue persists. (this will make your app use the native php sessions and bypass any of F3's session handlers)

Also check your ip before and after the refresh that triggers the issue and see if there are any changes. It's doubtful but as you appear to be using ipv6 maybe there's something that changes it? 

[v.]

Hi,

Yes I am using f3's session class. It is initiated in the index file.

Disabling it returns a 500 error on  $this->f3->session->csrf():

Call to a member function csrf() on null

[ved]

Hi, 

Yeah, if you're using the session's csrf feature then you'll have to use one of F3's session handlers.

For the Session class, you need to have the cache enabled in order to test correctly, so make sure your CACHE variable is enabled.

The session's onsuspect handler appears to be getting triggered and that's what gives you the 403 status. That only happens when user agent or ip address changes as you can see here.

You can setup a callback function for the onsuspect event and run some checks inside that callback to see what could be wrong. See here for an example.

Alternatively, you can try to use the SQL or Mongo Session handlers, that also have the csrf() feature and see if there are any changes in the behavior.

Other than that, I'm sorry but I can't really see anything wrong with F3 itself on this issue so it's probably something else in your code/code flow.

If you have any more details or are willing to post some more of your initialization/main controller code then maybe we can help further.

Cheers

[v.]

Thank you for your help ved, with this I found out that my IP actually gets changed from ip6 to ip4 and back. This seems to be causing the problem.

I have never seen this causing issues anywhere before and it does not seem to be happening in chrome. I did see it in edge once or twice.

When I put the site on a different server it does not happen.

Any ideas on this? Is it my ISP that is causing this problem or maybe a local PC / infrastructure configuration issue?

[ved]

Cool, no problem. Glad you found the cause of the issue.

But I'm not really sure on how to best deal with this issue as I'm still on ipv4 and my knowledge of ipv6 is pretty poor.

I'm guessing that your system sees that you have two internet connected ip's and just uses one or the other randomly.

A Ctrl+refresh probably cleans any potential ip binding for that browser session and occasionally probably starts using the other ip, triggering the error on F3.

Maybe you can disable ipv4 or ipv6 completely on your system, which should leave you with just one internet connected address and prevent that issue.

Cheers

[xfra35]

Look at this: https://www.quora.com/Why-would-my-computer-randomly-switch-from-IPv4-to-IPv6

Couldn't it be that your server supports both protocols v4/v6 while the "different server" does only support v4?

In that case, it would mean that the framework suspicious session detector is a bit too strict. You can disable it like this:

new Session(function(){
  return TRUE; // all sessions are OK
});

[v.]

Thanks for the help in this both of you.

I am learning things I did not even know were possible...

Stupid question probably, but where exactly would this code go?

[ved]

Add it where you initialize your F3 Session class.

Instead of something like:

$sess = new \Session();

You can set it up as stated by @xfra35:

$sess = new \Session(function() { return true; });

By returning true on the callback, F3 will bypass the 403 error and your session should remain valid even if your ip or user agent changes.