I have a website with an authentication form that users must use to access the site.
When Google Chrome is used to access the site, there is no offer to save the user's credentials, despite browser settings being set to allow. The FORM tag is not using autocomplete="off", but it is running over HTTPS if that makes any difference.
What do I need to do (or not do) for Chrome to offer to save passwords?
FYI - the site in question can be seen here.
It turns out that the issue was caused by the tag missing the action attribute.
Added action="" and all is good, even with AJAX and GET.
I don't think chrome remembers usernames and passwords sent via AJAX. The only thing you can do is make it submit the form normally.
Apart from Nathan's observation on the use of XHR to post the credentials, it is quite possible that the use of the HTTP GET instead of the HTTP POST request is responsible for Chrome's behavior in not offering to save the credentials.
It should be noted, that using HTTP GET instead of POST to submit credentials is often considered a bad practice in itself, notwithstanding the annoyance encountered in Chrome. Although I cannot pinpoint any specific problems in this case (as I haven't seen the post-login page, and other related traffic), using GET to transmit credentials is something you would want to avoid (to prevent any potential leaking of credentials, despite the use of HTTPS).
Related
I have been developing a system in .NET MVC and have up until had no problems logging in; however today I tried to log in on Chrome and the form is not being submitted instead I get the following error in the console:
This page includes a password or credit card input in a non-secure context.
A warning has been added to the URL bar.
For more information, see [Link Here]
I have verified that the log in page works in another browser (Firefox) and can confirm there is no issue in that browser. Is there something I can do short of converting to a HTTPS site, this is a test server for the company I work at and so they don't use HTTPS on in development websites.
I would expect (as Uwe Keim mentions) that you'd want to heed the warning and maybe discuss with your colleagues WHY they aren't testing with HTTPS if they use (or will use) it in Live? Self signed certificates can be used for these things so it doesn't involve a cost for internal-only development kit.
If that is a no-win situation, perhaps you may gain some benefit by adding it to your trusted sites list?
I'm working on an AIR app that logs a user in to a remote website. At certain points during the session the user may need to open a page in their browser. When they do that they are not logged in according to the browser so the user must login again. I'm trying to login them in through the browser when they login in the application.
I've read that AIR can manage cookies. I think it's doing that but I'm not sure. Is there a way to share cookies with the browser? Is that what manage cookies setting does?
If none of that is happening could I create a mx:HTML instance or stage web view and double login with that? A stage webview should be using the system browser correct? The same browser that will launch when navigateToURL() is called.
UPDATE:
It looks like cookies are shared across browsers except in a few cases such as Firefox and Linux. Update again, cookies are shared less often than initially thought. It looks like I might be able to login a user by creating a StageWebView instance. I will have to double check to make sure it's a default browser and not the internal webkit.
UGH. It looks like StageWebView on the desktop uses the internal webkit. There is a useNative property though. But even if I can use a native system browser I'm not sure how to log someone in with it because I don't think I can post to it? I think I can only set the URL which would be a get...
...It looks like I can create a post request and then use navigateToURL() to load that request. It would be hacky but it might work.
ARG. It looks like AIR doesn't support post through navigateToURL().
I don't know why you want to complicate things by thinking just to use POST ?! You can use GET by sending some temporary identifier ( token, hash, ... ), like some websites do with their user's newsletter when they give you the possibility to log in just by clicking a simple link in that newsletter, which will be generated by your server side script after that your user has been successfully identified, then when the user opens that link in the browser you can verify that information and then create your cookies ...
Hope that can help.
I'm using an API on my website to send emails to the users and while testing my call I noticed I was receiving the email twice.
So the url looks like "localhost/api/sendEmail" and, at least on Chrome, when I'm on localhost and I start typing "/ap" the url is automatically completed.
And I can see on Fiddler that Chrome (well I think that's him) is actually calling it before I press Enter so the mail is sent, and when I press Enter it is of course sent a second time.
This is not a problem since it won't be directly callable by the end-user, but I was just wondering what is the purpose of this first call ? Is Chrome pre-calling the page to make it faster to load ? Can it cause problems in different situations? Can one prevent Chrome from behaving like this?
Again, not a problem at all, but I'm just wondering.
This is Google's prefetch feature, which loads the page quicker, assuming you execute the auto-completed URL.
You can disable this option in Google Chrome:
Settings > Advanced Settings > Privacy: (uncheck) Prefetch resources..
Update 2019
I came across a similar question on superuser, which I provided an updated answer for.
Disable page load prediction service
chrome://settings/ -> expand Advanced section
Disable NoState Prefetch
chrome://flags -> search for "nostate"
Could a chrome extension be made that maintains a bitcoin wallet while also making it easy for web stores to integrate a one-click purchase experience.
Suppose a button on a webpage is clicked. Is it possible for that to trigger a function call to the chrome extension to send bitcoins?
Obviously letting webpages unlimited access to chrome extensions would never have been designed. But is there some way to make this work securely?
Chrome extensions can insert arbitrary code into web pages (content scripts).
Content scripts are JavaScript files that run in the context of web
pages. By using the standard Document Object Model (DOM), they can
read details of the web pages the browser visits, or make changes to
them.
This code can communicate with the original web page via the DOM and with the rest of the extension via message passing.
In theory, this should suffice. But make it secure, please.
Multibit provides an external application solution
Clicking on a "bitcoin:" protocol URI in Chrome (or any other browser) will transfer the URI over to MultiBit (v0.3+), starting the application if necessary. This approach removes the need for private keys to be held (and potentially shared) within the browser.
This is very dangerous because a single security hole in Chrome could allow any website to empty your wallet.
First, any payment have to be confirmed with the wallet password. But, as that password is typed inside Chrome itself, it might be possible for an attacker to read that password.
In fact, there are so many security issues to solve that I think it's better to let the bitcoin client do that job.
What should be done is a way for any software to ask the bitcoin client for a transaction. The first idea that comes to mind is using DBus.
That way, the Chrome extension would only have to transform any bitcoin address by a button which calls a DBus method.
The blockchain.info Bitcoin Wallet provides some support for this
by using navigator.registerProtocolHandler and Bitcoin URI's. Unfortunately it only works in firefox at present.
We have a secure website (SSL) in which we want to make calls to google's map server. The map server is http not https and every time there is a refresh of this screen (every minute for us) IE pops up its annoying mixed content message (trying to view a site with secure and non-secure info).
What I am looking for is a way around this. For example, is there a way to proxy the request so that our internal request is https but the other side of the proxy is not secure? I'm trying essentially to spoof the data to trick the browser.
Any ideas here? The actual security of the end point is less important than avoiding the error message itself.
Thanks!
Don
There is a way to suppress this at browser level, which might not be desirable for you, but I thought I'd throw it out there. In IE, Tools | Internet Options | Security | Internet Zone | Custom dialog box, you can set the "Display mixed content" to Enable. It's probably on prompt right now. Again, this is a single user browser level setting, so probably will not work for you. This does open up a lot of problems security wise though, and most admins will not do this (DNS poisoning, m-i-m etc).
Your second option is to become a premier customer: http://code.google.com/apis/maps/faq.html#ssl
Your third option is to use Virtual Earth - which supports native SSL w/o any strings
EDIT see similar question: here
As of March 2011, the Google Maps API is available to everyone over SSL:
http://googlegeodevelopers.blogspot.com/2011/03/maps-apis-over-ssl-now-available-to-all.html
Here's the problem with that. Even though the API is SSL the thumbnail images the map has for locations are NOT ssl. So you can still get a message.
remove runat="server" from head, where you are using code to link API to your page