We've been trying to implement a site with a http home page, but https everywhere else. In order to do this we hit the rather big snag that our login form, in a lightbox, would need to fetch a https form using ajax, embed it in a http page and then (possibly) handle the form errors, still within the lightbox.
In the end we gave up and just made the whole site https, but I'm sure I've seen a login-in-a-lightbox implementation on other sites, though can't find any examples now I want to.
Can anyone give any examples of sites that have achieved this functionality, or explain how/why this functionality can/can't be achieved.
The Same Origin Policy prevents this. The page is either 100% HTTPS or it's not. The Same Origin Policy sees this as a "different" site if the protocol is not the same.
A "lightbox" is not different than any other HTML - it's just laid out differently. The same rules apply.
One option would be to use an iFrame. It's messy, but if having the whole shebang in https isn't an option, it can get the job done.
you might be able to put the login form into an iframe so that users can login through https while it seems they are on a http page,
but im not sure why you would want to do this.
Related
Is there a way to make sure Magento calls secure urls when its in the checkout process? The problem is the web browser complains when over httpS because not all resources are secure. In the source I have things like <script type="text/javascript" src="httP://something"> which triggers this error. I'm afraid customer won't think the site is secure.
I know I can use this <?php $this->getUrl('something/', array('_secure'=>true)) ?> However I don't want all my javascript resources to be secure all the time, just in the checkout process.
It seems Magento should handle this automatically when you configure it use frontend SSL, but apparently not.
So my question is what is the best way to handle this?
Thanks
The customer would be correct - the page content is not secure.
If you hardcode protocols in markup or incorrectly specify protocols in code, the system delivers what you ask. It's incumbent on the implementer to make sure the markup is correct.
That said, asset sources can use relative protocols in markup:
<script src="//cdn.com/some.js"></script>
Also, secured/non-secured status can be passed dynamically to arguments.
Magento serves out everything secure that it controls. The problems usually come from scripts that load content from other sites. Magento doesn't have any control over these. It would have to literally rewrite the script in order to do that.
It's your responsibility to see that the scripts are properly written or else banished to pages where they belong so the browser doesn't complain about insecure content.
A case where relative protocols did not work. --->> We took on Authorize.NET and chewed them out because of their security badge causing Internet Explorer to pop up the insecure content warning during cart operations, the very place you want the badge to show so the customer knows their credit card info is being properly handled. They had the problem fixed within two weeks after we told them people were not ordering and actually complaining about site security when we showed their badge in the cart.
It was caused because the script they gave you at the time, which we tried to modify for relative protocol, then turned around and called yet another script that retrieved plain ole port 80 insecure content.
Facebook can go like itself on another page, it doesn't belong in cart operations (another script menace we had to deal with).
I need to display some data(some text message) from a URL*(an HTML file)* which is in a different domain. I thought about using an iFrame to display the markup. Now the problem could be
if that site is down, then I wil see 404 error in that iFrame. i want to avoid that. I thought about using dojo to make an AJAX call to that URL to get the response, use innerHTML
to insert the response to the DOM. This is all what I need. But due to cross domain AJAX issues, I don't think it is possible. We are using dojo in our application. I searched
in Google to find a good implementation of Cross Domain scripting using Dojo. All I found is stuffs like JSONP. I don't want to make the remote domain return a JSONP. It is
just an HTML file and that file contains the markup that I need to print to the console. Can someone suggest a good way to do this.
Sadly as was already mentioned by Nakul in the comments, the same-origin policy does not allow for cross-domain XHR requests (at least in a cross-browser way).
The workarounds involve either cooperation from the cross-domain site (JSONP, CORS, various iframe communication tricks) or setting up a proxy in your own server so that all "cross-domain" go through your own domain first.
I'm coding a site that makes heavy use of AJAX to load pages for users with JavaScript, but I also want it to be friendly for users with JavaScript disabled or unavailable. I've covered all the basics; for example, all my links point to canonical links, and JavaScript loads them via AJAX. My "about" page, therefore, is located at /about/, but will load on the main page and will, once finished, utilize hash/hashbang links to enable back-button functionality.
Here's the problem I have: while a hash/hashbang link will be able to be used to link to a specific page via AJAX for users with JavaScript, if a user with JavaScript attempts to link someone without it to the page, the page cannot be loaded for that person using AJAX.
As such, I'd like to be able, if possible, to use .htaccess to redirect hash/hashbang-specified pages to the canonical link. In other words, the exact opposite of what this contributer was trying to achieve.
http://example.com/#!about --> http://example.com/about/
Is it possible with .htaccess, or otherwise without JavaScript? If so, how?
Thanks!
I don't think it's possible to do this on server side. Because the part of the url after # is not included in the request sent to the server.
I might be a bit late to the party on this one, but i'm looking into this too. Since your url already contains the #!, as opposed to #, you can actually do this. Google will fetch
http://example.com/#!about
as
http://example.com?_escaped_fragment_about
Therefore, if you use a redirect 301 on that, and use javascript to redirect the user only version of the page, you have practically reached your desired result.
I realise you asked for a no-javascript solution, but i figure that was for reasons of SEO. For more information, please see this page by google.
EDIT:
<meta http-equiv="refresh" content="5; url=http://example.com/">
Some more on meta refresh here.
It:
1) Does not require javascript!
-
2) Can be Seo friendly!
-
3) Works with bookmarks and history (etc.)
I hope this helps!
So Google takes:
http://www.mysite.com/mypage/#!pageState
and converts it to:
http://www.mysite.com/mypage/?_escaped_fragment_=pageState
...So... Would be it fair game to redirect that with a 301 status to something like:
http://www.mysite.com/mypage/pagestate/
and then return an HTML snapshot?
My thought is if you have an existing html structure, and you just want to add ajax as a progressive enhancement, this would be a fair way to do it, if Google just skipped over _escaped_fragment_ and indexed the redirected URL. Then your ajax links are configured by javascript, and underneath them are the regular links that go to your regular site structure.
So then when a user comes in on a static url (ie http://www.mysite.com/mypage/pagestate/ ), the first link he clicks takes him to the ajax interface if he has javascript, then it's all ajax.
On a side note does anyone know if Yahoo/MSN onboard with this 'spec' (loosely used)? I can't seem to find anything that says for sure.
If you redirect the "?_escaped_fragment_" URL it will likely result in the final URL being indexed (which might result in a suboptimal user experience, depending on how you have your site setup). There might be a reason to do it like that, but it's hard to say in general.
As far as I know, other search engines are not yet following the AJAX-crawling proposal.
You've pretty much got it. I recently did some tests and experimented with sites like Twitter (which uses #!) to see how they handle this. From what I can tell they handle it like you're describing.
If this is your primary URL
http://www.mysite.com/mypage/#!pageState
Google/Facebook will go to
http://www.mysite.com/mypage/?_escaped_fragment_=pageState
You can setup a server-side 301 redirect to a prettier URL, perhaps something like
http://www.mysite.com/mypage/pagestate/
On these HTML snapshot pages you can add a client-side redirect to send most people back to the dynamic version of the page. This ensures most people share the dynamic URL. For example, if you try to go to http://twitter.com/brettdewoody it'll redirect you to the dynamic (https://twitter.com/#!/brettdewoody) version of the page.
To answer your last question, both Google and Facebook use the _escaped_fragment_ method right now.
Lets just say that I wanted to be extra careful with the website I'm visiting (irrespective of whether the site is offered in https) and wanted to convert every href in the web page received into its https equivalent.
Is there a way/add-on to do this ? or do I have to write my own :(
As Paul said, most sites will break if you do this. However, if you wanted to do something similar to this (grabbing all the links on a page and doing something to them), a Greasemonkey script would be easier and quicker than writing a Firefox add-on.
You can't just point all links to https, most of them will break, and secure sites will redirect you to https anyway.