I'm trying to submit a form back to my server using POST and the target is at the same domain (which is HTTPS) however when I submit I get a Mixed Content error. Does the form post not follow the same protocol as the hosting page? If so what is the best way to fix it without always specifying the full url (I use sub domains for different companies)
Does the form post not follow the same protocol as the hosting page?
It does if a relative URL is specified.
e.g. path relative
action="/form/foo"
or protocol relative
action="//example.com/form/foo"
It appears you have something on your action page, or the page that it redirects to loading over plain HTTP. Use developer tools to hunt out this reference.
Related
I am learning HTML, and whenever I execute the href function in HTML and click the blue text, the browser tries to redirect me to a folder inside my computer, when in reality I want to enter a website. For example, if I try to execute the following code, instead of the browser redirecting me to duckduckgo.com, it tries to redirect me to a folder inside my computer:
Browse anonymously and without being traced
How can I solve this issue?
Because href="duckduckgo.com" is using a relative URL, so the browser is looking for duckduckgo.com relative to the current URL that is displaying the page. To the browser it's no different than if you used href="index.html", both are structurally identical.
Instead, use a fully-qualified URL:
Browse anonymously and without being traced
You can also default to the current protocol with this:
Browse anonymously and without being traced
So if the current page is open via http:// or https:// then the link would use the same in the resulting request. Note however that your description of "a folder inside my computer" may somewhat imply that your current protocol could be file://, in which case an inferred protocol clearly wouldn't work. The point is, the structure of a complete URL is pretty versatile so you have options.
I did a search and could not find an answer on here to my question. What I am confused about is what URLs on an https page need to be https, as opposed to http.
I am making a series of pages my website that must be accessed over https. At the top of the pages is a menu. I accidentally included a style sheet into the page using http, instead of https, and all the browsers I tried gave me a warning about insecure content. But, I can leave the menu links at the top of the page http, and there's no problem.
So, am I correct in saying that things that are being loaded onto the page, such as style sheets and images, need to have https in the link, but that plain old href links can just have http in them?
Thanks for your advice.
Generally your secure pages such as purchase page, credit card etc processing pages are set to https or sometimes all pages such as websites for banks or other financial institutes or even login pages.
You can leave it to browser to deciper http or https part by using what is called protocol-relative URLS in which you simply do not specify either of http or https and still browser will be able to figure it out. An example:
//example.com
//google.com
Let's say your domain is foo.com, you would specify all URLs like:
//foo.com/page1.html
//foo.com/otherpage
So you simply leave the http or https part in your URLs.
To know more about protocol-relative URLS, see:
http://paulirish.com/2010/the-protocol-relative-url/
Yes, all links that are used to create the page itself (the HTML, the CSS, JavaScript, the images) need to be served over https. That means all URLs of that domain need to be served over https.
Links to other websites can be http just fine. You may want to check if those links can be visited over https as well because then the user will use a secure connection to visit those website as well.
Is there a reason we include the http / https protocol on the href attribute of links?
Would it be fine to just leave it off:
my site
The inclusion of the “http:” or “https:” part is partly just a matter of tradition, partly a matter of actually specifying the protocol. If it is defaulted, the protocol of the current page is used; e.g., //www.example.com becomes http://www.example.com or https://www.example.com depending on the URL of the referring page. If a web page is saved on a local disk and then opened from there, it has no protocol (just the file: pseudo-protocol), so URLs like //www.example.com won’t work; so here’s one reason for including the “http:” or “https:” part.
Omitting also the “//” part is a completely different issue altogether, turning the URL to a relative URL that will be interpreted as relative to the current base URL.
The reason why www.example.com works when typed or pasted on a browser’s address line is that relative URLs would not make sense there (there is no base URL to relate to), so browser vendors decided to imply the “http://” prefix there.
URLs in href are not restricted to only HTTP documents. They support all the protocols supported by browsers- ftp, mailto, file etc.
Also, you can preceed URL name with '#', to link to a html id internally in the page. You can give just the name or directory path, without a protocol, which will be taken as a relative URL.
My solution was to trick the browser with a redirect service, such as bit.ly and goo.gl (which will be discontinued soon), in addition to others.
When the browser realizes that the url of the shortcuts is https, it automatically releases the link image, the link is released and instead displays the http image, without showing the original link.
The annoying part is that, according to the access, it will display in the panel control of your redirector, thousands of "clicks", which is actually "display".
With this experience I'm going to look for a Wordpress plugin for redirection and create my own "redirects links". So I will have https // mysite.com /id → redirect to http link.
I have a website in which every page is served via HTTPS. On one of the pages I have a form whose action attribute is set to a relative URL.
The page with the form can only be accessed via HTTPS and the page the form posts to can only be hit via HTTPS, yet in IE I get a security warning telling me I'm about to switch to an insecure connection. Is there any way to prevent this problem beyond codding the full URL including the protocol into the form's action attribute?
Update:
I tried hardcoding the entire URL and still I get the pop-up.
The relevant code is:
<html>
<body>
<form action="https://mydomain.com/editProfile">
...
</form>
</body>
</html>
As soon as I click the submit button in IE6 I get a security alert pop-up. If I click ok, the result page is displayed and the protocol is still HTTPS. I'm starting to wonder if it is the form POST that's causing the issue.
You can't (other than setting the base URL to https). According to RFC 1808 (relative URLs), an URL starting with a scheme name is always interpreted as an absolute URL (section 4, step 2a).
(As others pointed out, relative URLs keep the scheme, so the problem was elsewhere, probably with an unencrypted image or CSS file, but the question was interesting in its own right.)
Internet explorer is notorious for demanding that there are NO http requests in your https page or the security popup pops up.
Are all your links in the page relative?
Are there no hidden redirects in your webserver?
Think about pictures/css files/javascript files, can they all be retrieved using https?
I have a page on a website that contains a secure form inside an iframe. Although the form data submitted is secure the page doesn't appear secure as the URL in the browser is just HTTP. Is there anything I can do to show the users that the form is secure?
Although the form data submitted is secure
It may or may not be encrypted. But it's not secure, and the browser is absolutely correct to deny you a padlock icon.
If the parent page is http, then that page could easily have been altered by a man-in-the-middle attack to point the usually-secure <iframe> to a completely different server to the expected one. Or, the parent page might have had JavaScript injected into it to log any keypresses you make into the form and send them to the attacker's server.
The user would have no way of checking whether this had happened, short of viewing the page source and reading and understanding every line of markup and script inside it. This is absolutely unrealistic.
If you aren't on a page where all content is secured by https, any submission from that page is insecure, regardless of where the form action is pointed.
Open the form in a new window or host the container page on a secure server. Users have a right to be skeptical of an insecure page hosting a supposedly secure page -- it's practically begging for XSS attacks.
Whether the host page is secured or not, placing https secured pages inside an iframe is not a good idea. Even https pages are not invulnerable to xss and MIM attacks. The only way to avoid any confusion as to which domain/web server your web browser is talking to is go direct to the source page - i.e. the one you are trying to put inside your iframe.
Iframes are a convenient way to quickly include content from another page/site, but they open up a whole bunch of opportunities to the dishonest!
Nothing that will trigger the usual browser "This is secure" indicators.