I am having issues when doing anything with views on my server with a security certificate.

The url is [URL removed at the request of the poster]

It displays a bunch of code on the page and doesn't go back to the interface.

The code starts off - { "display": "\x3cform action=\"/admin/build/views/ajax/add-item/store/default/field\" ...

I don't have this issue with the same environment without a security certificate.

Comments

merlinofchaos’s picture

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

If you see that code, it probably indicates that the javascript somehow failed. If using firefox, can you look at the error console and see what message it has in there?

drfuzetto’s picture

drfuzetto commented

I am getting this error:

Error: [Exception... "'Permission denied to call method XMLHttpRequest.open' when calling method: [nsIDOMEventListener::handleEvent]" nsresult: "0x8057001e (NS_ERROR_XPC_JS_THREW_STRING)" location: "" data: no]

I am not sure how to fix this. Does something need to change on the server?

Please give me some information that I pass on to my IT person.

Thanks,
deborah

merlinofchaos’s picture

merlinofchaos commented

My guess is that the URL you're visiting and the URL that the AJAX wants to go to have different domains, and the browser is choking due to cross-domain scripting protections.

When you see the { "display} does the domain in the URL there match the domain in the URL when visiting the view?

Also, if you're getting https by having apache perform a redirect, this might also be causing an issue with the AJAX calls.

drfuzetto’s picture

drfuzetto commented

I added the base_url to the settings file and it seems to have fixed my problem.

drfuzetto’s picture

drfuzetto commented

Hi merlinofchaos -
I cannot edit the original but wanted to have the url that I provide removed.
Can you remove the domain part of that url.
Thanks,
Deborah

merlinofchaos’s picture

merlinofchaos commented

URL removed.

drfuzetto’s picture

drfuzetto commented

thank you!

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
commented
Status: Postponed (maintainer needs more info) » Closed (duplicate)

Comment #4 states another workaround, but I still think this is an issue to figure out in #347753: Ajax returned as new page when updating a field.

iamjon’s picture

iamjon commented
Version: 6.x-2.0-beta4 » 6.x-3.x-dev
Status: Closed (duplicate) » Active

I'm reopening this issue as #347753: Ajax returned as new page when updating a field became a bit too hectic and delved into other issues.

This particular issue seems to be caused when part of a site is in http and another is in https, but is not limited to http https, in some cases it has to do with server configs.

I'm attaching excepts from my conversation with merlinofchaos on irc as well as from the original issues that can be helpful in solving this.
From the Original Issue:

  • Views encodes the base_url into the settings. It's that base_url that is not getting corrected by whatever is making https links.
  • Check to see if base_url matches the actual URL being used and if it does not, override it. That one is probably more tedious than anything since there isn't a single place that ajax links are handled, and to do this there will need to be.

From my conversation with merlinofchaos

In javascript, when making AJAX calls through the normal method (and there are other methods with other limitations), you are limited to making them to the same domain you're visiting. i.e, when visiting http://www.example.com I can't make an AJAX call to http://example.com because these are not the same domain.

Similarly, and this is the problem we see most often: When visiting http://www.example.com we cannot make an AJAX call to https://www.example.com -- despite the actual DNS portion of the name being the same, it is a different service. And by the rules of javascript, considered a different domain.

What happens a lot is when secure pages is installed, it tries to make an AJAX call from the secure domain to the non-secure domain (or vice-versa) and javascript says NO and blammo

zap-admin’s picture

zap-admin commented

I'm having the exact same issue..... http vs https and views not liking that. I went into settings.php and actually added a second base_url with "https".....

I don't know if I've read some of these posts correctly or not. The addition of the second base_url in the settings file cleared up the issue. Should I have remarked out the original "base_url" ? So there would be none showing in this part of the settings.php file?

Sorry to be annoying, just wanting to see if I can get any kind of further clarification.

Thanks,
Jeffrey

Anonymous’s picture

Anonymous (not verified) commented
Version: 6.x-3.x-dev » 6.x-2.12

Hmm wacky problem. :-)

The backend was working fine until the last update views-6.x-2.12. But what I read on the subject, unless I'm missing something, is that this is a problem which keeps showing up.

In https turning javascript on and off in the settings of views does not appear to solve it.

I have https and http set in settings.php, and it was working fine. So I am hesitant to say that is causing the problem. Sounds like something is wacky.

Logging in through http, and everything works fine.

Does views store any paths in the database? Maybe something gets overridden there?

I'm really strapped for time, but I'll try in the coming weeks to setup a local install, export all views, and remove the views module completely, and then re-install. Sometimes that kick starts a module into working correctly. If that doesn't work a clean install with a clean views, and see if it works then.

merlinofchaos’s picture

merlinofchaos commented
Status: Active » Closed (won't fix)

A re-install won't help you here.

The error is fundamentally this:

If you are at https://www.example.com an AJAX call to http://www.example.com cannot be made.

Views generally just uses the path that's given in the link, and the absolute paths are provided by Drupal itself. So there's very little that Views, itself, can do about this; generally it's the fault of whatever is providing the https/http switch not doing it correctly.

Anonymous’s picture

Anonymous (not verified) commented

Thank you for your reply and providing the information. Appreciate it.

So would hardcoding the url in the module solve the problem?

The next step we could do is maybe put a form in the settings of views. This with a text something like: 'If you are having problem with secure pages (https) then enter the https address here.' Then store the address, and have views use this value. Would that solve it?

What do you think?

yang_yi_cn’s picture

yang_yi_cn commented

for people who are still interested in this issue. It looks like it works if you set $base_url, and the site is not multilingual.

If you have domain based language negotiation, even if you set the $base_url to https, the url() function will generate the URLs that have base_url rewritten from language.inc. Thus the "https" set in the settings php will lost.