PHP get_browser() matches browser string with names only - that shouldn't happen. about browscap HOT 13 CLOSED

I can't reproduce this using browscap/browscap-php - I'm assuming from the referenced issue GaretJax/phpbrowscap#33 that this is fixed now :)

from browscap.

Nope, it's not fixed. I've just patched it in phpbrowscap, but the source problem still exists.

echo "<pre>";
var_dump(get_browser('WebTV'));

if you do that, you will see that there was a positive match. There shouldn't be, because 'WebTV' is just a group name, not an user agent.

from browscap.

I'd suggest that is a bug in PHP's get_browser implementation then ;)

from browscap.

That is a fair suggestion, but I don't think it's the case in this situation. :)

It's a fundamental flaw in the browscap ini files, where entries:

[WebTV]
Parent=DefaultProperties
Comment="WebTV/MSNTV"
Browser="WebTV/MSNTV"
Platform="WebTV"
Frames=true
IFrames=true
Tables=true
Cookies=true

[Mozilla/3.0 WebTV/1.*(compatible; MSIE 2.0)]
Parent=WebTV
Version=1.0
MajorVer=1
MinorVer=0

have identical format, even tough the first one is a group entry and the second one a match entry. The hack I did in phpbrowscap is checking for 'Comment' field, but that's just a hack and there is no guarantee that you won't add a 'comment' field to a match entry or forget it in a group entry.

And, as I have described above, group entries and match entries are not identical, because the first ones should not be checked against the user agent. That's where this error originates. Mind you, it's not a very important problem as it only adds some incorrect matches to browser strings that are not used by legitimate user agents. Or at least I think so.

from browscap.

The regex generated should not match just WebTV, as the regex should be ^WebTV$ not WebTV. If the regex to be matched is the latter, then yes, the "group" entry will match before the "match" entry. Could that be the cause of the issue?

I only say this because something like this would've been picked up a long time ago... :/

from browscap.

Another example: the match entry you pointed out above should generate the regex /^mozilla/3\.0 webtv/1\..*\(compatible; msie 2\.0\)$/gi and the group entry should be /^webtv$/gi... so the group entry will not match but the match entry itself will.

from browscap.

In whatever way you write the regexes, there are two regexes being generated from that ini file:

1. from [WebTV] section name
2. from [Mozilla/3.0 WebTV/1.*(compatible; MSIE 2.0)] section name
   The first one should not be created at all.

And the problem isn't real browsers matching wrong patterns, but that if someone sets their user agent to WebTV then it will be matched by get_browser because of the /^webtv$/gi regex. Thus it will give you incorrect result, because user agent string WebTV is not a correct user agent and should match 'default browser'.

from browscap.

Ah, I see what you mean, apologies for playing catch-up. I can't imagine this would be a major problem - if people are forcing their UAs to something like that, the browscap detection is going to be screwed anyway :/

from browscap.

Yeah, I doubt there could be many cases in which someone would experience this bug on accident, by either using legitimate user agent or just setting them randomly.

However, it's still a bug and imho it should stay open.

from browscap.

In my Pascal Version of the browscap.ini parser I check at first for exact match, that means I look if an section without wildcard is matching, if a exact match occurs and the Parent isn't 'DefaultProperties' I take that match, otherwise I'm looking for a match with wildcards.

from browscap.

I have tried to solve this issue.
The only way I found was to remove all group entries from the ini files and merge their properties into the match entries. Because of that the size of the full php ini file increased up to 38MB. And I needed to remove the comment property to get this working with the current browscap-php version.

from browscap.

I don't think it is worth solving this, it's not that big an issue imo.

from browscap.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

from browscap.