My client's site is having an intermittent issue where the source code of the Cosign login page is getting pasted directly into some of the cached JS files for the site (/sites/default/files/js). This is then causing issues on the site, namely the javascript for the Insert module is not working because of a syntax error.

Here's an example of a javascript file that has the code pasted into it (you have to scroll all the way to the bottom):

http://iha.umich.edu/sites/default/files/js/weird-cosign-insert-issue.js

I haven't been able to identify exactly when/how this happens. But once I realize the insert isn't working, I just find the .js files that have this code, remove the code, and then everything is good again. Until the next time it happens...

Any thoughts?

Comments

kevinchampion’s picture

kevinchampion commented
Status: Active » Postponed (maintainer needs more info)

This sounds to me like a javascript caching problem. My interpretation of what's likely happening is that when drupal tries to wrap all the javascript up into a single cached file, it's finding one of those files is protected and thus it's requiring authentication for it to access it. So instead of printing the javascript file to the cached javascript, it's printing the result of the GET request which is being redirected to the central weblogin Cosign login page. As a result, you end up with HTML in your cached javascript file, which should invalidate all the javascript.

From inspecting the HTML from the Cosign login page, there is a hidden input element with a name attribute called 'ref'. It appears that 'ref' represents referrer, which is the page that Cosign weblogin was referred from (ie. in this case, the protected javascript file). So, to try to figure this out, the key is to find out what is happening to the javascript file in this input element:

https://iha.umich.edu/sites/default/files/js/wysiwyg/wysiwyg_ckeditor_uW...

I can't say with any certainty what exactly is happening with this file. There's a chance that it has the wrong afs/unix file permissions, which would ordinarily return a 403 error. In this case though, something may be configured to redirect such a 403 to try to authenticate. Another possibility is that the javascript is being included as an absolute path with the https protocol, which would automatically trigger a redirect to cosign weblogin if the user was not already authenticated. However, I'm not very certain that either of these hypotheses are plausible.

In any event, this problem seems to be specific to the server configuration and/or the way the particular javascript file is being included, and not a Cosign module issue.

If you investigate this file and the server configuration and still find that you think the culprit is the Cosgin module, report back with your findings and additional details.

mlhess’s picture

mlhess commented
Status: Postponed (maintainer needs more info) » Closed (cannot reproduce)

Agreed. This looks like server config.

I am going to mark this closed, as I have not been able to reproduce it.

icm’s picture

icm commented

Thanks guys!

It's definitely connected to the "Aggregate JavaScript files" setting. If I disable that, clear out all the cached JS files (in /sites/default/files/js), then re-enable it and navigate the public site, everything is fine and I don't see the "cosign login" source code in any of the cached JS files. However, as soon as I login and go to an edit page that uses the Insert module, then more cached JS files are generated and that source code shows up in one of them. Your explanation totally makes sense - something is requesting a protected file during the javascript aggregation/caching process, which then triggers the redirect to the Cosign login page. I just don't understand why/how it would trigger the login. Hopefully I'll be able to figure out what's making the request. For the time being, I'm just going to disable the cosign module. Thanks!