Hello all,
Just now I noticed that I’m unable to delete a submission guideline.
Apparently a Chrome known issue…
I’m running Chrome on anonymous window.
I also tried on regular window, cleared site cookies, browser cookies, and nothing… still unable to clear the guideline.
It’s displaying the following error:
ERR_BLOCKED_BY_XSS_AUDITOR
Anyway to overcome this yet?
Hi @ramon,
Do you have any links to discussions of this as a known Chrome issue?
Regards,
Alec Smecher
Public Knowledge Project Team
Hello @asmecher,
Sorry to respond so late…
Note that saving the form and changing language is ok. Just excluding author guideline elements is blocked.
I googled for chrome ERR_BLOCKED_BY_XSS_AUDITOR and these came up.
Chrome forum, in portuguese: Google Product Forums
Also, this problem only happens in Chrome, apparently! I tried Firefox and it works fine.
Someone posted this as a solution in the portuguese forum:
<?php header("X-XSS-Protection: 0; mode=block"); ?>Hi @ramon,
Do your guidelines include content from another server?
Regards,
Alec Smecher
Public Knowledge Project Team
Hello @asmecher,
Some of them have URLs to pages and documents within OJS itself (one is a link to a Word document in another journal’s public folder, the other a static page within the journal!). Here’s the link to the submission guidelines.
The guideline I wanted to exclude had a link to the default text on providing a safe blind peer-review, but I don’t know anymore if the link pointed to the old installation… That could be it… Now that I have excluded it, hard to know.
[UPDATE]
The content was copied and pasted from another installation, which could be the reason for the XSS exception. However, the server’s main domain was http://revista.ibict.br, and that was kept untouched. There may have had /index.php/journal-path in there, though.
Suddenly, this morning, got this error on changing a journal title image.
Apparently there is a Google over protection issue, it is still unsolved on Chrome 61.etc.
I’m running OJS 2.82.
No issues on Firefox.
I tried to disable the “XSS_AUDITOR” service by modifying the Chrome’s link:
“C:\Program Files (x86)\Google\Chrome\Application\chrome.exe” -disable-xss-auditor
It works.
I’m not sure about the other implications of such measure.
Any impressions?
Hi @nepos,
It would be possible to add a header in OJS that would disable Chrome’s XSS protection, but I’m hesitant do that as it seems to be site-specific, i.e. Chrome doesn’t seem to be broadly incompatible with anything we’re doing in OJS. If you want to disable this check for your site, see this page’s suggestions on configuring the X-XSS-Protection header via a .htaccess file, or (as you’ve noted) you can start your browser with the checking disabled.
If this seems to be a systemic problem, then we can re-examine, but I don’t have that sense yet.
Regards,
Alec Smecher
Public Knowledge Project Team
My OJS install started to give me those errors when I change the language or try to exclude itens from the checklist or anything that changes the page in the Step 3 of the Journal Setup.
Even a blank Journal created as a test is giving me the error, no links or outside content anywhere.
I don’t know what is causing the problem. I thought it was the javascript:openHelp in the checklist but it seems to be something else.
Hi @luizborges,
I’m not able to duplicate that behavior here – you’ll need to investigate further to see what’s triggering it. If you’re comfortable doing so, you could PM me temporary credentials privately so I can see myself if there’s something unusual.
Regards,
Alec Smecher
Public Knowledge Project Team
Hi @luizborges,
Yes, I think it’s the Javascript call in the checklist item that’s causing this, at least on your setup form. Chrome is capturing this because it’s watching for requests to OJS that include Javascript code. You could either add a X-XSS-Protection header to disable checking in the PHP code, or you could remove the JS, or you could use another browser (or disable checking in your browser) to submit this form as a work-around (since it’s an administrator form and not likely to get regular use).
Regards,
Alec Smecher
Public Knowledge Project Team
What is curious is that this never happened before.
Now, the Javascript code was always there in OJS, so something must have changed in Chrome. Now, I think this must be dealt with as an open issue with OJS. Removing the JS code is not a fix, because this cannot be done for everyone and every install. Using another browser is also not a fix, just a workaround. Thus we are left with the header to disable the checking and a “proper” fix if the Javascript function will remain being called (and backwards compability call for it).
How should I go on implementing that? I’m not the sole manager on my server and we have almost 20 journals, so I need a fix for this problem.
PS: Would you consider this as an Issue to be patched and fixed?
Hello all,
I solved my problem changing Chrome’s XSS configurations.
It prevents execution of some OJS pages… I don’t particularly remember where it is, but searching the Web and Chrome’s settings may help. Since it worked on Firefox, I assumed it was a browser issue.
Hi all,
If you want to add the X-XSS-Protection header, you can do it near the other header calls in PKPTemplateManager.inc.php in the display function. However, it’s probably better to do this at the web server level, e.g. using Apache’s mod_headers (mod_headers - Apache HTTP Server Version 2.4).
I’m not seeing this showing up widespread so I suspect it’s tied to some combination of your browser, server, and journal configuration. This is a bit like the mod_security posts that come up in the forum: OJS is doing a legitimate and non-dangerous thing, but a heuristic-based tool is mistakenly intercepting it as a security problem. In my opinion the heuristic is the problem; OJS is behaving fine.
Regards,
Alec Smecher
Public Knowledge Project Team
Done, I used the following in apache to set it off:
<IfModule mod_headers.c>
Header set X-XSS-Protection "0"
</IfModule>