beforeroute($f3, $params) - $f3['PATTERN'] and $f3['ALIAS'] null?

[PJH]

Occasionally in the following:

public function beforeroute($f3, $params)

{

$this->m("URI: " . $f3['URI']);

$this->m("PATTERN: " . compact_dump($f3['PATTERN']));

$this->m("ALIAS: " . compact_dump($f3['ALIAS']));

PATTERN and ALIAS are coming up null. Anyone any suggestions on where I should be looking to figure out why?

Examples  of it working as expected:

Tue, 12 Apr 2022 11:30:19 +0000 [2602:ffd5:1:219::1] app/resources/pjh::beforeroute(111): URI: /question/f0ab717b-6567-4ab4-8217-a69110a15f70
Tue, 12 Apr 2022 11:30:19 +0000 [2602:ffd5:1:219::1] app/resources/pjh::beforeroute(112): PATTERN: : (string) "/question/@question_id"
Tue, 12 Apr 2022 11:30:19 +0000 [2602:ffd5:1:219::1] app/resources/pjh::beforeroute(113): ALIAS: : (string) "showQuestion"

and

Tue, 12 Apr 2022 12:29:35 +0000 [207.46.13.110] app/resources/pjh::beforeroute(111): URI: /establishment/fb294f55-9b2d-4991-a2e4-19e1afe021c0
Tue, 12 Apr 2022 12:29:35 +0000 [207.46.13.110] app/resources/pjh::beforeroute(112): PATTERN: : (string) "/establishment/@establishment_id"
Tue, 12 Apr 2022 12:29:35 +0000 [207.46.13.110] app/resources/pjh::beforeroute(113): ALIAS: : (string) "show_establishment"

and

Tue, 12 Apr 2022 12:28:22 +0000 [40.77.167.16] app/resources/pjh::beforeroute(111): URI: /
Tue, 12 Apr 2022 12:28:22 +0000 [40.77.167.16] app/resources/pjh::beforeroute(112): PATTERN: : (string) "/"
Tue, 12 Apr 2022 12:28:22 +0000 [40.77.167.16] app/resources/pjh::beforeroute(113): ALIAS: : (string) "home"

And where it isn't working as I expect, with the same base URL's:

Tue, 12 Apr 2022 11:34:53 +0000 [66.249.79.13] app/resources/pjh::beforeroute(111): URI: /question/5d80076e-0ca5-4edf-9ce4-28eea6bac6d8
Tue, 12 Apr 2022 11:34:53 +0000 [66.249.79.13] app/resources/pjh::beforeroute(112): PATTERN: : NULL
Tue, 12 Apr 2022 11:34:53 +0000 [66.249.79.13] app/resources/pjh::beforeroute(113): ALIAS: : NULL

and

Tue, 12 Apr 2022 11:50:44 +0000 [66.249.79.11] app/resources/pjh::beforeroute(111): URI: /establishment/a59eb797-a51c-467b-8cfb-12cb6e9ef0b8
Tue, 12 Apr 2022 11:50:44 +0000 [66.249.79.11] app/resources/pjh::beforeroute(112): PATTERN: : NULL
Tue, 12 Apr 2022 11:50:44 +0000 [66.249.79.11] app/resources/pjh::beforeroute(113): ALIAS: : NULL

and

Tue, 12 Apr 2022 11:57:07 +0000 [35.189.121.87] app/resources/pjh::beforeroute(111): URI: /
Tue, 12 Apr 2022 11:57:07 +0000 [35.189.121.87] app/resources/pjh::beforeroute(112): PATTERN: : NULL
Tue, 12 Apr 2022 11:57:07 +0000 [35.189.121.87] app/resources/pjh::beforeroute(113): ALIAS: : NULL

Of note, the ones that aren't working are all google searchbots (but they do work most of the time,) the ones where it is are MSN (which is why I didn't obfuscate the IPaddresses)

One example of it working, then suddenly not:

Tue, 12 Apr 2022 12:28:30 +0000 [x.y.z.w] app/resources/pjh::beforeroute(111): URI: /establishment/226
Tue, 12 Apr 2022 12:28:30 +0000 [x.y.z.w] app/resources/pjh::beforeroute(112): PATTERN: : (string) "/establishment/@establishment_id"
Tue, 12 Apr 2022 12:28:30 +0000 [x.y.z.w] app/resources/pjh::beforeroute(113): ALIAS: : (string) "show_establishment"
Tue, 12 Apr 2022 12:28:31 +0000 [x.y.z.w] app/resources/pjh::beforeroute(111): URI: /establishment/67be9733-bcc9-4490-8245-ea525d44135e
Tue, 12 Apr 2022 12:28:31 +0000 [x.y.z.w] app/resources/pjh::beforeroute(112): PATTERN: : (string) "/establishment/@establishment_id"
Tue, 12 Apr 2022 12:28:31 +0000 [x.y.z.w] app/resources/pjh::beforeroute(113): ALIAS: : (string) "show_establishment"
Tue, 12 Apr 2022 12:28:32 +0000 [x.y.z.w] app/resources/pjh::beforeroute(111): URI: /establishment/67be9733-bcc9-4490-8245-ea525d44135e
Tue, 12 Apr 2022 12:28:32 +0000 [x.y.z.w] app/resources/pjh::beforeroute(112): PATTERN: : NULL
Tue, 12 Apr 2022 12:28:32 +0000 [x.y.z.w] app/resources/pjh::beforeroute(113): ALIAS: : NULL


Routes defined for the above:

$f3->route('GET|HEAD @showQuestion: /question/@question_id', 'PJH\Question->show');

$f3->route('GET|HEAD @show_establishment: /establishment/@establishment_id', 'PJH\Establishment->show');

$f3->route('GET|HEAD @home: /', 'PJH\Page->home');

Help?

[ved]

Hello,

Try to check if those requests that failed have the http header "Access-Control-Request-Method"

Both PATTERN and ALIAS are set on this line where the condition only triggers if the request verb exists in your routes (GET or HEAD in your case) but also that this is not a preflight request as defined here.

Also, access to the headers for the request and/or webserver logs for the requests may help debug the issue.

Cheers

[Paul Herring]

Ta, ved, I'll stick some extra logging in tomorrow. 

How should I be handling such requests if they are preflight? They all seem to be GET requests that are trying to access URIs that could return either 200 or 403 (I normally match against the PATTERN to determine which.)

--
-- 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 a topic in the Google Groups "Fat-Free Framework" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/f3-framework/Vg8tm9eWVbQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to f3-framework...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/f3-framework/1964d64f-efe2-43ef-8941-4523a664f017n%40googlegroups.com.

[ved]

Hi,

Note that I'm not suggesting that what I posted above is the actual cause for your issue.

I just took a quick glance at the code where those variables are set and that was the first thing that came up as a possible cause.

As for how you should handle those requests specifically, I'm not sure as I've personally never had to deal with that.

I have also never used the PATTERN as a way to decide which http code to return.

Are you actually doing something like:  if PATTERN === '/establishment/@establishment_id' ? 

Because that seems to be almost duplicating what the routing system is already doing.

Surely there must be another way to decide if your content is forbidden or not by using some other application variable (i.e.: from your app's data/logic and not F3)?

Cheers

[Paul Herring]

> Are you actually doing something like:  if PATTERN === '/establishment/@establishment_id' ? 

Centralised RBAC. Starts with the pattern, digging down into any variables that are there if necessary. 

Saves me duplicating the logic/calls in all the separate classes that handle different routes. (Establishment, and Question that were listed being only two of many.) Deriving all the classes from a common base didn't work out when I tried it way back when. 

I'll have a play around tomorrow and see what comes up; from reading up on preflight stuff since my last email, I think I can get away with 'not supporting it;' seems to be CORS related, which isn't really relevant to my site. 

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 view this discussion on the web visit https://groups.google.com/d/msgid/f3-framework/29222246-bcb2-470c-9cba-d42f53fb2efbn%40googlegroups.com.

[ved]

Hi,

Ok, I guess it's a valid use, wasn't really criticizing, was just something that I never even considered.

Also, you probably already know about it, but for a pretty decent access control plugin you have xfra35's f3-access plugin which is quite handy and may be useful and/or extendable for your use-case.

Do let us know if you eventually figure out the issue or have any more information from the logs/headers/etc.

Cheers.

[Paul Herring]

> xfra35's f3-access plugin 

Ah. No; I was unaware of that (doesn't ring bells from when I was looking for stuff at the start of my site rewrite). Will also look at that tomorrow. 

That said, the site this is for is a hobby site, and the RBAC stuff a learning exercise on doing that sort of thing from scratch. 

>Do let us know if you eventually figure out the issue or have any more information from the logs/headers/etc.

Will do! 

To view this discussion on the web visit https://groups.google.com/d/msgid/f3-framework/3e8902ea-bdf5-412e-aaa7-65099847b02an%40googlegroups.com.

[Paul Herring]

> Try to check if those requests that failed have the http header "Access-Control-Request-Method"

They aren't; they seem to be just regular GET requests. Two failures from Googlebot:

Wed, 13 Apr 2022 11:11:53 +0000 [66.249.79.9] app/resources/pjh::beforeroute(135): VERB: GET, URI: /image/5fd549e27932da6c92c97e35b9a0d02e.jpeg
Wed, 13 Apr 2022 11:11:53 +0000 [66.249.79.9] app/resources/pjh::beforeroute(136): PATTERN: , ALIAS:
Wed, 13 Apr 2022 11:11:53 +0000 [66.249.79.9] app/resources/pjh::pattern_alias_hack(122): PATTERN: /image/*, ALIAS:
Wed, 13 Apr 2022 11:11:53 +0000 [66.249.79.9] app/resources/pjh::beforeroute(146): HEADERS: ['']{
Wed, 13 Apr 2022 11:11:53 +0000 [66.249.79.9] ....Accept-Encoding: (string) "gzip, deflate, br"
Wed, 13 Apr 2022 11:11:53 +0000 [66.249.79.9] ....User-Agent: (string) "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/100.0.4896.75 Mobile Safari/537.36
(compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
Wed, 13 Apr 2022 11:11:53 +0000 [66.249.79.9] ....From: (string) "googlebot(at)googlebot.com"
Wed, 13 Apr 2022 11:11:53 +0000 [66.249.79.9] ....Accept: (string) "image/avif,image/webp,image/apng,image/svg+xml,image/*,*/*;q=0.8"
Wed, 13 Apr 2022 11:11:53 +0000 [66.249.79.9] ....Connection: (string) "keep-alive"
Wed, 13 Apr 2022 11:11:53 +0000 [66.249.79.9] ....Host: (string) "www.example.com"
Wed, 13 Apr 2022 11:11:53 +0000 [66.249.79.9] ....Cache-Control: (string) "no-store, no-cache"
Wed, 13 Apr 2022 11:11:53 +0000 [66.249.79.9] ....Referer: (string) "https://www.example.com/question/9fe8bc65-ce41-4c9b-8cbc-d216afaff827"
Wed, 13 Apr 2022 11:11:53 +0000 [66.249.79.9] ....Cookie: (string) "session_id=ec1h8gs6a6t2363k3jdo3irfcd"
Wed, 13 Apr 2022 11:11:53 +0000 [66.249.79.9] ....Accept-Language: (string) "en-US"
Wed, 13 Apr 2022 11:11:53 +0000 [66.249.79.9] ....Content-Length: (string) ""
Wed, 13 Apr 2022 11:11:53 +0000 [66.249.79.9] ....Content-Type: (string) ""
Wed, 13 Apr 2022 11:11:53 +0000 [66.249.79.9] }
Wed, 13 Apr 2022 11:11:54 +0000 [66.249.79.9] app/resources/pjh::beforeroute(135): VERB: GET, URI: /image/5fd549e27932da6c92c97e35b9a0d02e.jpeg
Wed, 13 Apr 2022 11:11:54 +0000 [66.249.79.9] app/resources/pjh::beforeroute(136): PATTERN: , ALIAS:
Wed, 13 Apr 2022 11:11:54 +0000 [66.249.79.9] app/resources/pjh::pattern_alias_hack(122): PATTERN: /image/*, ALIAS:
Wed, 13 Apr 2022 11:11:54 +0000 [66.249.79.9] app/resources/pjh::beforeroute(146): HEADERS: ['']{
Wed, 13 Apr 2022 11:11:54 +0000 [66.249.79.9] ....Accept-Encoding: (string) "gzip, deflate, br"
Wed, 13 Apr 2022 11:11:54 +0000 [66.249.79.9] ....User-Agent: (string) "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; Googlebot/2.1; +http://www.google.com/bot.html) Chrome/100.0.4896.75 Safari
/537.36"
Wed, 13 Apr 2022 11:11:54 +0000 [66.249.79.9] ....From: (string) "googlebot(at)googlebot.com"
Wed, 13 Apr 2022 11:11:54 +0000 [66.249.79.9] ....Accept: (string) "image/avif,image/webp,image/apng,image/svg+xml,image/*,*/*;q=0.8"
Wed, 13 Apr 2022 11:11:54 +0000 [66.249.79.9] ....Connection: (string) "keep-alive"
Wed, 13 Apr 2022 11:11:54 +0000 [66.249.79.9] ....Host: (string) "www.example.com"
Wed, 13 Apr 2022 11:11:54 +0000 [66.249.79.9] ....Cache-Control: (string) "no-store, no-cache"
Wed, 13 Apr 2022 11:11:54 +0000 [66.249.79.9] ....Referer: (string) "https://www.example.com/question/9fe8bc65-ce41-4c9b-8cbc-d216afaff827"
Wed, 13 Apr 2022 11:11:54 +0000 [66.249.79.9] ....Cookie: (string) "session_id=34ovh5iad5vivn7gv77qvvgcb3"
Wed, 13 Apr 2022 11:11:54 +0000 [66.249.79.9] ....Accept-Language: (string) "en-US"
Wed, 13 Apr 2022 11:11:54 +0000 [66.249.79.9] ....Content-Length: (string) ""
Wed, 13 Apr 2022 11:11:54 +0000 [66.249.79.9] ....Content-Type: (string) ""
Wed, 13 Apr 2022 11:11:54 +0000 [66.249.79.9] }

Two successful requests from the same bot, same URL (asking for it directly here, rather than as referral from the HTML page that contains the image):

Wed, 13 Apr 2022 11:28:47 +0000 [66.249.79.25] app/resources/pjh::beforeroute(135): VERB: GET, URI: /image/5fd549e27932da6c92c97e35b9a0d02e.jpeg
Wed, 13 Apr 2022 11:28:47 +0000 [66.249.79.25] app/resources/pjh::beforeroute(136): PATTERN: /image/*, ALIAS:
Wed, 13 Apr 2022 11:28:47 +0000 [66.249.79.25] app/resources/pjh::pattern_alias_hack(122): PATTERN: /image/*, ALIAS:
Wed, 13 Apr 2022 11:28:47 +0000 [66.249.79.25] app/resources/pjh::beforeroute(151): HEADERS: ['']{
Wed, 13 Apr 2022 11:28:47 +0000 [66.249.79.25] ....Accept-Encoding: (string) "gzip, deflate, br"
Wed, 13 Apr 2022 11:28:47 +0000 [66.249.79.25] ....User-Agent: (string) "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
Wed, 13 Apr 2022 11:28:47 +0000 [66.249.79.25] ....From: (string) "googlebot(at)googlebot.com"
Wed, 13 Apr 2022 11:28:47 +0000 [66.249.79.25] ....Accept: (string) "*/*"
Wed, 13 Apr 2022 11:28:47 +0000 [66.249.79.25] ....Connection: (string) "keep-alive"
Wed, 13 Apr 2022 11:28:47 +0000 [66.249.79.25] ....Host: (string) "www.example.com"
Wed, 13 Apr 2022 11:28:47 +0000 [66.249.79.25] ....Content-Length: (string) ""
Wed, 13 Apr 2022 11:28:47 +0000 [66.249.79.25] ....Content-Type: (string) ""
Wed, 13 Apr 2022 11:28:47 +0000 [66.249.79.25] }
Wed, 13 Apr 2022 11:28:48 +0000 [66.249.79.13] app/resources/pjh::beforeroute(135): VERB: GET, URI: /image/5fd549e27932da6c92c97e35b9a0d02e.jpeg
Wed, 13 Apr 2022 11:28:48 +0000 [66.249.79.13] app/resources/pjh::beforeroute(136): PATTERN: /image/*, ALIAS:
Wed, 13 Apr 2022 11:28:48 +0000 [66.249.79.13] app/resources/pjh::pattern_alias_hack(122): PATTERN: /image/*, ALIAS:
Wed, 13 Apr 2022 11:28:48 +0000 [66.249.79.13] app/resources/pjh::beforeroute(151): HEADERS: ['']{
Wed, 13 Apr 2022 11:28:48 +0000 [66.249.79.13] ....Accept-Encoding: (string) "gzip, deflate, br"
Wed, 13 Apr 2022 11:28:48 +0000 [66.249.79.13] ....User-Agent: (string) "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/100.0.4896.75 Mobile Safari/537.3
6 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
Wed, 13 Apr 2022 11:28:48 +0000 [66.249.79.13] ....From: (string) "googlebot(at)googlebot.com"
Wed, 13 Apr 2022 11:28:48 +0000 [66.249.79.13] ....Accept: (string) "*/*,application/signed-exchange;v=b3"
Wed, 13 Apr 2022 11:28:48 +0000 [66.249.79.13] ....Connection: (string) "keep-alive"
Wed, 13 Apr 2022 11:28:48 +0000 [66.249.79.13] ....Host: (string) "www.example.com"
Wed, 13 Apr 2022 11:28:48 +0000 [66.249.79.13] ....Amp-Cache-Transform: (string) "google;v="1..2""
Wed, 13 Apr 2022 11:28:48 +0000 [66.249.79.13] ....Content-Length: (string) ""
Wed, 13 Apr 2022 11:28:48 +0000 [66.249.79.13] ....Content-Type: (string) ""
Wed, 13 Apr 2022 11:28:48 +0000 [66.249.79.13] }

Headers returned for that URL from my server on a successful retrieval:

 curl -LI https://www.example.com/image/5fd549e27932da6c92c97e35b9a0d02e.jpeg
HTTP/2 200  
server: nginx
date: Wed, 13 Apr 2022 11:32:19 GMT
content-type: image/jpeg
set-cookie: session_id=s9plrdacq0gvfb58bgug1ihcg1; path=/; domain=www.example.com; secure; HttpOnly; SameSite=Lax
x-frame-options: SAMEORIGIN
x-xss-protection: 1; mode=block
x-content-type-options: nosniff
pragma: no-cache
cache-control: no-cache, no-store, must-revalidate
expires: Thu, 01 Jan 1970 00:00:00 +0000
x-frame-options: SAMEORIGIN
x-content-type-options: nosniff
x-xss-protection: 0;
strict-transport-security: max-age=31536000; includeSubDomains
referrer-policy: no-referrer-when-downgrade

[ved]

Hi,

Well, that is indeed strange.

On the requests where the the alias and pattern return null I'm assuming that the route itself isn't even called right? Or does it return those as null but still executes what you have on your route method?

Maybe you can you try to access those url's by emulating a bot? Either by using chrome's developer tools emulation or google search console's "fetch as bot" (or something like that).

I also see that you're using nginx as your webserver. Usually (although it depends on configuration) any requests for a file that exists bypasses F3 completely and just serves the file directly.

Although in that case I'm guessing it wouldn't even run the beforeroute code, so it's most likely not the case :-\

But just in case, if you can post your nginx configuration maybe it can help further reduce and rule out causes for the problem.

Other than that, I'm really not sure why that is happening, although I have that feeling that it will probably be something obvious that we're missing :P

Cheers

[Paul Herring]

On Wed, Apr 13, 2022 at 1:54 PM ved via Fat-Free Framework <f3-fra...@googlegroups.com> wrote:

Hi,

Well, that is indeed strange.

On the requests where the the alias and pattern return null I'm assuming that the route itself isn't even called right? Or does it return those as null but still executes what you have on your route method?

Well, since no pattern was matched, then it won't know which route to call, no? I've got beforeroute() returning false in those instances now anyway.

 

Maybe you can you try to access those url's by emulating a bot? Either by using chrome's developer tools emulation or google search console's "fetch as bot" (or something like that).

I got the headers from generating requests from https://search.google.com/search-console/inspect (which fetches as Googlebot.)

 

I also see that you're using nginx as your webserver. Usually (although it depends on configuration) any requests for a file that exists bypasses F3 completely and just serves the file directly.

None of the URI's mentioned so far are actual files extant on the server (even the image URI's go through an F3 handler since they're in a hashed directory structure - something akin to the answer here: https://stackoverflow.com/a/466938)

In fact the only things that are literal files, are things like css and js stuff.

 

Although in that case I'm guessing it wouldn't even run the beforeroute code, so it's most likely not the case :-\

But just in case, if you can post your nginx configuration maybe it can help further reduce and rule out causes for the problem.

# Redirect 80=>443

server {

listen 80;

listen [::]:80;

server_name example.com;

return 301 https://www.$host$request_uri;

}

server {

listen 80;

listen [::]:80;

server_name www.example.com;

return 301 https://$host$request_uri;

}

# www.example.com

server {

listen 443 ssl http2; # managed by Certbot

listen [::]:443 ssl http2;

server_name www.example.com;

root /var/www/example.com/www;

access_log /var/log/nginx/access.www.example.com.log;

error_log /var/log/nginx/error.www.example.com.log;

index index.php index.html index.htm index.nginx-debian.html;

location ~ /restricted/.* {

return 404;

}

# exceptions to /app/

location ~ /app/(css|js)/.* {

try_files $uri /index.php?$query_string;

}

# but block everything else

location ~ /app/.* {

return 404;

}

location ~ /backups/.* {

return 404;

}

location ~ /\..* {

return 404;

}

location ~ /tmp/.* {

return 404;

}

location / {

try_files $uri /index.php?$query_string;

}

location ~ \.php$ {

include snippets/fastcgi-php.conf;

fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;

}

ssl_certificate /etc/letsencrypt/live/example.com-0002/fullchain.pem; # managed by Certbot

ssl_certificate_key /etc/letsencrypt/live/example.com-0002/privkey.pem; # managed by Certbot

include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot

ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

}

# redirect example.com to www.example.com

server {

listen 443 ssl http2; # managed by Certbot

listen [::]:443 ssl http2;

server_name example.com;

return 301 http://www.$host$request_uri;

# listen [::]:443 ssl ipv6only=on; # managed by Certbot

ssl_certificate /etc/letsencrypt/live/example.com-0002/fullchain.pem; # managed by Certbot

ssl_certificate_key /etc/letsencrypt/live/example.com-0002/privkey.pem; # managed by Certbot

include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot

ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

}

 

Other than that, I'm really not sure why that is happening, although I have that feeling that it will probably be something obvious that we're missing :P

Well, I'll keep digging; might find something...

--

PJH

[Paul Herring]

Not sure, but I think I've identified one... thing? Not sure why it's a problem, and it looks terribly obscure, but...

Google's triggering onsuspect() from DB\SQL\Session() - overriding it to return true all the time (from it being a null function) seems to fix the null PATTERN/ALIAS:

onsuspect() returning false:

Wed, 13 Apr 2022 14:09:27 +0000 [66.249.79.21] www/example.com/www::PJH\{closure}(66): ONSUSPECT: user changed browser/device:Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; Googlebot/2.1; +http://www.google.com/bot.html) Chrome/99.0.4844.84 Safari/537.36
Wed, 13 Apr 2022 14:09:27 +0000 [66.249.79.21] app/resources/pjh::beforeroute(135): VERB: GET, URI: /image/5fd549e27932da6c92c97e35b9a0d02e.jpeg
Wed, 13 Apr 2022 14:09:27 +0000 [66.249.79.21] app/resources/pjh::beforeroute(136): PATTERN: , ALIAS:
Wed, 13 Apr 2022 14:09:27 +0000 [66.249.79.21] app/resources/pjh::pattern_alias_hack(122): PATTERN: /image/*, ALIAS:

onsuspect() returning true:

Wed, 13 Apr 2022 14:10:22 +0000 [66.249.79.19] www/example.com/www::PJH\{closure}(66): ONSUSPECT: user changed browser/device:Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.84 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
Wed, 13 Apr 2022 14:10:22 +0000 [66.249.79.19] app/resources/pjh::beforeroute(135): VERB: GET, URI: /image/5fd549e27932da6c92c97e35b9a0d02e.jpeg
Wed, 13 Apr 2022 14:10:22 +0000 [66.249.79.19] app/resources/pjh::beforeroute(136): PATTERN: /image/*, ALIAS:
Wed, 13 Apr 2022 14:10:22 +0000 [66.249.79.19] app/resources/pjh::pattern_alias_hack(122): PATTERN: /image/*, ALIAS:

Identified when I was investigating an occasional, and separate "session_commit(): Cannot call session save handler in a recursive manner" error and was prompted to go look at onsuspect() from this (very old) post.

[ved]

Hey,

Yeah, everything appears to be as expected, no pattern or alias so the route will obviously not run (was just asking as the entire thing is a bit strange :). Nginx config also appears correct AFAICS.

Try editing F3's base.php file and just placing some debugging statements before and after any relevant conditions to try and figure out where exactly it's failing?

Other than that, i'm kind of stumped so not sure what else to suggest, sry. Maybe some of the developers that have a deeper knowledge of the core innerworkings of the framework can shed some light into what's happening. Paging @ikkez @bcosca :D

PS:

Just saw your update on the onsuspect event. The default action is to trigger a 403 when a session's user agent or ip changes so maybe that's something to do with it(?)

Try removing F3's session handler so that it just uses the regular PHP session handler and see if that fixes the issue.

That issue of the "recursive manner" was already fixed IIRC. Do you have the latest F3 version? And also what's your php version, because some recent changes were made for php 8 and 8.1 support that may (but probably not) be causing some bug somewhere

Keep us updated :-)

Cheers.

[Paul Herring]

> Do you have the latest F3 version? And also what's your php version,

No - F3 3.7.3, and php 7.4 at the moment (see nginx.conf previously.)

Should probably look to upgrade both...

--
-- 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 a topic in the Google Groups "Fat-Free Framework" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/f3-framework/Vg8tm9eWVbQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to f3-framework...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/f3-framework/15776699-ccd5-43ee-a8cf-c5ed92a92c17n%40googlegroups.com.

--

PJH

[Paul Herring]

> Google's triggering onsuspect() from DB\SQL\Session() - overriding it to return true all the time (from it being a null function) seems to fix the null PATTERN/ALIAS:

What's actually happening, should it matter to anyone (from debug put into \DB\SQL\Session::read(), if onsuspect() needs to be called):

$l = new \Log('<...>');

$l->write("ONSUSPECT: new ip ".$this->_ip." agent ".$this->_agent);

$l->write("ONSUSPECT: old ip ".$this->get('ip')." agent ".$this->get('agent'));

Result on forcing them to do it:

Thu, 14 Apr 2022 11:00:53 +0000 [66.249.79.19] ONSUSPECT: new ip 66.249.79.19 agent Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.84 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
Thu, 14 Apr 2022 11:00:53 +0000 [66.249.79.19] ONSUSPECT: old ip 66.249.79.19 agent Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/100.0.4896.75 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)

Quite why they're doing that, I dunno.

Off to tidy up what I've done so far with this, then upgrade some things (F3 first, to see if this is still an issue in 3.8)...

--

PJH

[v.]

Late in the discussion, but I have seen similar things (I think) with google and other bots: the first request to a page returns a 403, if I dirty hack things so that all 403's reload the same page they do get that page.

Overriding the onsuspect function solves this issue entirely.

I never managed to figure out why this happened.

[ved]

Hi,

Yes I'm also completely out of ideas about this or why the googlebot is doing that in the first place.

I'll note that I usually also override the onsuspect callback to remove those useragent and ip change triggers, not specifically because of this, but mostly because I've found some other situations where it hinders some things.

Most notably during development and/or testing if one is frequently using chrome's mobile view (that changes the user agent) or behind some corporate internet setups that use multiple outgoing internet connections, or when browsing from a mobile device using mobile data that then switches to using wifi when it finds an available access point (and vice versa), etc.

Still, if you have any new test data and/or find the solution for this, please keep this thread updated as it will probably be of some help to future viewers.

Cheers.