Magento Secure/Unsecure Items During Checkout - security

Magento 1.6
I'm looking for the correct way, to place images on a template, that are secured during a secure session, and unsecured, during an unsecure session. I've searched here and on the web and the only solution I have come to find is to use this call:
echo $this->getSkinUrl('images/imagename.jpg', array('_secure'=>true));
However, this ALWAYS loads the image in https, even when you are not in an https environment.
There has to be a dynamic way of setting this up.
Any help / insight available is greatly appreciated.
Thanks!

Did you try :
array('_forced_secure'=>true)
Check :
core/Mage/Core/Model/Url.php

Related

WWW version of website is showing at the end of the URL [domain]index.php?p=index.html

We have a website set up using the non WWW version of the website. At the moment when you access the WWW version of the domain it seems to redirect to www.ourdomain.com/index.php?p=index.html.
We are seeing the homepage template but with errors. (e.g. Images aren't loading). Does anyone know what would be the best way to fix what is happening or the potential causes.
You can use your browsers web inspector tools to see why assets like images aren't loading. Quite possibly it's because they are trying to load from the wrong domain.
If you didn't set the site URL in /craft/config/general.php then the URL set in your admin site settings will be used, so check that is correct first.
Removing the index.php?… part is covered in detail in Craft's Documentation so not worth repeating here.

Has anyone experienced Cloudflare 403 Errors with zombie.js web scraping?/

We're looking to do some scraping on a specific URL that uses cloudflare. Has anyone experienced issues using Zombie.js/user-agents while trying to crawl cloudflare hosted sites.
Would love some help!
I am trying to interface to an API on a client's site and I am getting a 403 error indeed. The request doesn't even reach my server.
Turning security to "essentially off" did not help. The final solution was to white-list the developer machine's IP.
The error is triggered on a single URL (json serving API) with a Java client with standards compliant libraries.
Solution:
1. try to set a rule to allow direct access for that URL
2. try setting security to weaker and weaker ("essentially off")
3. if both fails: try whitelisting
4. set up an alternate non-cloudflare url (direct.domain.com)
These will of course only work if you can negotiate with the site owners.
Backup solution: use an embedded browser that you can "frame" and "remote control" or a testing framework that does the same through a plugin, and extract the content from there (if you can)
Hope this helps.
You're probably triggering one of our security features by trying to scrape a site on us. The only option, really, would be to ask the site owner to whitelist your IP(s) to override the behavior.

Redirect page to secure page

I cant seem to find an exact answer on the web to suit my problem. I'm trying to redirect/rewrite:
http://www.ccy.com.au/availability/booking.asp
https://secure.ccy.com.au/availability/booking.asp
SSL has been setup on secure domain. It's been done through plesk(v11.0.9_build20120609.17 os_Windows 2008) and I'm using IIS 7.5
Is there a way to achieve this sort of redirect/rewrite as I'm very new to server related tasks. Thank you in advance!
p.s I'll provide other information I may have missed!
In your booking.asp file, can you simply do:
<%
Response.Redirect("https://secure.ccy.com.au/availability/booking.asp")
%>

How to find that current url is rewritten?

That's no surprise that same couchapp can be build to work either with rewrites on or off.
I wonder, is there a way or a technique to find out on a client side whether rewrites are currently working, i.e. current url is rewritten?
Please share.
Within list and show functions you can access req.requested_path that should help you with that. As of CouchDB 1.1.1, this is not working in all situations, I guess it just delivers a meaningful value if you access your CouchApp via a vhost, but I have to check that.
With CouchDB 1.2 there's a change coming that could help you with that:
https://github.com/apache/couchdb/blob/master/CHANGES#L103
"The requested_path property keeps the pre-rewrite path even when no VHost configuration is matched."
Hope this helps!

SSL: Why does Chrome report mixed content? (Drupal 6)

I've just got a site running nicely with the whole site running through SSL, but Google Chrome is throwing a "This page contains some insecure elements" message, which isn't good in terms of end user trust-ability. All other browsers work fine, and give the golden padlock.
The site is a Drupal 6 e-commerce site, running on apache2, and the error appears in the front end as well as the admin area.
Does anyone know of any methods to find out exactly which elements are being considered insecure?
Edit: I've used Fiddler to check the traffic, and it really is all HTTPS. It even complains on the site holding page, which is very light and has no javascript etc on it...
It could be a browser issue? Have you tried restarting, or clearing all of your cache?
In Chrome, this is trivial. Hit ctrl+shift+j to open the developer tools, and it will plainly list the URL of the insecure content.
Try it on https://www.fiddler2.com/test/securepageinsecureimage.htm, for instance.
I just had a similar problem. Turns out it was a hardcoded background image URL in a CSS file.
You should particularly check any 3rd party stylesheets you are using, as they may hotlink to an image on another server.
Easy solution? Save those images to your server and change the URLs to relative paths in the CSS file.
Hope this helps!
Search the source for http:? Something like <Ctrl-U> <Ctrl-F> http: in firefox should do.
The insecure element is something loaded over insecure — non-https — connection, e.g. image, stylesheet, etc. you obviously need fully qualified URL to load insecure element/
Use Firebug plugin of Firefox. In the NET tab all file locations are shown clearly. Try to find any files that are obtained from http protocol.
It's probably related to this bug:
http://code.google.com/p/chromium/issues/detail?id=24152
Which is why a restart fixed it.

Resources