Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Charset or parsing error in Visitors View #3194

Closed
anonymous-matomo-user opened this issue Jun 5, 2012 · 12 comments
Closed

Charset or parsing error in Visitors View #3194

anonymous-matomo-user opened this issue Jun 5, 2012 · 12 comments
Labels
Bug For errors / faults / flaws / inconsistencies etc.
Milestone

Comments

@anonymous-matomo-user
Copy link

After updating to 1.8 there is an error representing some chars in the visitors log.

The name of my Blog ist "Banym's Blog"

I am not sure if it's a problem while updating the database or just representing of the data.

Now I am using 1.8.2 and the problem still exists. 1.7 and below was fine.

Regards,

Dominik
Keywords: charset, visitors log

@anonymous-matomo-user
Copy link
Author

Attachment: Screenshot visitory log
screenshot-visitors-log.png

@diosmosis
Copy link
Member

(In [6518]) Fixes #3194, make sure smarty escape modifier doesn't double encode escaped text.

@mattab
Copy link
Member

mattab commented Jul 20, 2012

please revert as Dangerous to change the escape mechanism used in piwik - i'm pretty sure this would lead to XSS.

in this case there would be another reason for the bug, that the data was tracked incorrectly in the first place - maybe that "In DataTable/Renderer.php formatValueXml calls html_entity_decode/htmlspecialchars with ENT_COMPAT instead of ENT_QUOTES. Is this intentional?"

@diosmosis
Copy link
Member

Replying to matt:

please revert as Dangerous to change the escape mechanism used in piwik - i'm pretty sure this would lead to XSS.

in this case there would be another reason for the bug, that the data was tracked incorrectly in the first place - maybe that "In DataTable/Renderer.php formatValueXml calls html_entity_decode/htmlspecialchars with ENT_COMPAT instead of ENT_QUOTES. Is this intentional?"

This specific bug is caused because the action name has ' in it and the smarty escape modifier will encode it as '. The action name has ' due to getRequestVar sanitizing the action name when tracking.

I suppose, instead of modifying the escape modifier, I could decode the action name in the Live plugin, but other than decoding before escaping, I can't think of a way to solve this issue...

@diosmosis
Copy link
Member

(In [Refs #3194, reverted 6518) smarty escape modifier change.

@mattab
Copy link
Member

mattab commented Jul 23, 2012

I suppose, instead of modifying the escape modifier, I could decode the action name in the Live plugin, but other than decoding before escaping, I can't think of a way to solve this issue...

Did you replicate the original issue? I'm wondering if this is due to a tracker bug, or maybe just a browser bug? or were you able to have an example that fails in all browsers?

Actually banym How do the Page names display in the Actions>Pages and Page Titles report? do the report show the names with the html entities?

Thanks for further information!

@diosmosis
Copy link
Member

Replying to matt:

I suppose, instead of modifying the escape modifier, I could decode the action name in the Live plugin, but other than decoding before escaping, I can't think of a way to solve this issue...

Did you replicate the original issue? I'm wondering if this is due to a tracker bug, or maybe just a browser bug? or were you able to have an example that fails in all browsers?

I modified the VisitorGenerator plugin's access log, adding an "'" character to an entry's title. It showed up in the Visitor's log as "'". The HTML returned contained the text "'", so it is not a browser issue.

The action my test created had a name that looked like this: "incredible title''!". So either the bug is with the tracker when it stores action names in their sanitized state, or w/ the admin frontend.

Since decoding first is used in Piwik_Common::sanitizeInputValue, I assumed using it in the smarty escape modifier wouldn't be an issue.

@mattab
Copy link
Member

mattab commented Jul 24, 2012

Maybe the bug is in the tracker that should htmldecode before encoding? I thought it would do it already... Maybe that's a bug?

Can you confirm in your test that this page name is displayed correctly in Actions > Page Titles report?

@diosmosis
Copy link
Member

Replying to matt:

Maybe the bug is in the tracker that should htmldecode before encoding? I thought it would do it already... Maybe that's a bug?

Can you confirm in your test that this page name is displayed correctly in Actions > Page Titles report?

The page name is displayed correctly: "incredible title''!"

What a weird bug...

@mattab
Copy link
Member

mattab commented Jul 27, 2012

Could you do a special case of decoding the page title before encoding, in the Live plugins templates? what do you think?

@robocoder
Copy link
Contributor

Basically, we're double encoding: first in getRequestVar, and then here:

http://dev.piwik.org/trac/changeset/6104/trunk/plugins/Live/templates/visitorLog.tpl

I don't recall the problem fixed by r6104, but could it be changed to:

{$action.pageTitle|unescape|urldecode|escape:'html'|truncate:80:"...":true} 

@diosmosis
Copy link
Member

(In [6631]) Fixes #3194, committed vipsoft's fix: use unescape before escaping action name in visitor log.

@anonymous-matomo-user anonymous-matomo-user added this to the 1.8.3 - Piwik 1.8.3 milestone Jul 8, 2014
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug For errors / faults / flaws / inconsistencies etc.
Projects
None yet
Development

No branches or pull requests

4 participants