I have a form:
<form action="something.php" method="POST">
<input type="email" name="email"/>
<input type="submit" value="Send Email"/>
</form>
When someone tries to input some string that is not in email format the form won't let him. The only problem is that this dosen't work on Safari! Why!!!! http://www.w3schools.com/html/html5_form_input_types.asp
So what super easy work around can I use? Thank you
Let's be very clear on this point: while some HTML clients will respect the input type, several won't, and even if they do, it will not prevent anyone from forging an HTTP request where this field is not an email address. Therefore, you can rely on <input type=email> to provide a hint to users as to what should go in that field, but you shouldn't rely on it to make sure that only email addresses make it to your PHP script.
So some browsers support it, but Safari doesn't. That's pretty much all there is to it.
The correct solution, then, is to also do server-side validation and make it fail if it's not an email address. You can relatively easily check that with regular expressions.
Related
Is it possible to prevent autofill even when the creds are stored in the browsers logins and passwords?
Or is there a way to prevent creds being saved to the browser?
Or is it better to allow both of these browser features? I'm just think about security if people share machines.
I have tried autocomplete="off" on the inputs and form but it still autofills the fields if there is creds are already stored in the browser and if theyre not then it prompts to save them.
<form autocomplete="off">
<h1>Login</h1>
<input type="text" autocomplete="off" placeholder="username" />
<input type="password" autocomplete="off" placeholder="password" />
</form>
Any help would be appreciated!
It's because password autocompletion is not common autocompletion, most modern browsers are using some different mechanics to fill these fields. MDN says it can be disabled by adding autocomplete="new-password" to the fields, though it is new feature and may not work in some browsers. It surely works in Opera 68.
So your code should be something like this:
<form autocomplete="off">
<h1>Login</h1>
<input type="text" autocomplete="new-password" placeholder="username" />
<input type="password" autocomplete="new-password" placeholder="password" />
</form>
This question is actually answered here:
Disabling Chrome Autofill
If your inputs are actually a username and password, I wouldn't prevent the browser from recognising them as such.
The security issue with computer-sharing is a valid point, but personally I would say this is mostly up to the user. Most computers, for example, have optional settings that the computer password needs to be entered each time autofill is used in the browser. If I knew that my computer and account was being shared, I would definitely turn this setting on.
Also, the pop-up window which asks you to save the password should have the option Never for this website (at least that's how it's phrased in safari, I would assume all browsers offer something similar). If the user knows that a password opens up very sensitive information, they should always choose this option. The browser never saves a password without the user's permission.
As to why your code doesn't work – as far as I can see, you're using the autocomplete="off" attribute correctly, and it should work that way. I think the reason must be that your browser simply ignores this attribute for password inputs. Might be worth checking if the same thing happens in other browsers?
There appear to be many examples of Chrome ignoring this attribute in the past, with various more or less messy solutions. These questions, for example:
Chrome ignores autocomplete="off"
Chrome Officially Ignores Autocomplete Attribute (Reddit)
This is from MDN:
If a browser keeps on making suggestions even after setting autocomplete to off, then you have to change the name attribute of the input element.
I see you don't use a name attribute so please try that.
I have a web application written in HTML/PHP with a login screen. If a Chrome user logs in and navigates to a home page, the browser gives them the option of saving the password:
Some of our users who have hit 'save' will then see their username appear in a field that bears no relation to the login functionality:
The input field should look like this. With no value whatsoever:
This is the code for the input field:
<input type="text" id="searchInput" autocomplete="disabled" placeholder="Search..." >
And as per other questions, i have tried every single possible solution to disable any sort of auto-fill of this field via the autocomplete attribute but no luck..
Also, solutions like creating fake hidden fields didnt work either (this apparently used to work but Google discovered this practice and worked around it)
How can i stop Chrome from doing this?
Edit:
I have been able to get around this issue by setting the field initially to read only:
<input type="text" id="searchInput" onfocus="this.removeAttribute('readonly');" readonly autocomplete="disabled" placeholder="Search...">
In reality i shouldn't have to do this for every single field. But according to this, Google Chrome doesnt so much care about the usability of complex web interfaces likes those of CRM systems:
The tricky part here is that somewhere along the journey of the web autocomplete=off become a default for many form fields, without any real thought being given as to whether or not that was good for users. This doesn't mean there aren't very valid cases where you don't want the browser autofilling data (e.g. on CRM systems), but by and large, we see those as the minority cases. And as a result, we started ignoring autocomplete=off for Chrome Autofill data.
So those of us who happen to be working on "minority cases", are we doomed to have to write hacks like the above to prevent Chrome from inserting the username in a random place?
Have you tried setting the auto-complete types for the login fields? The following might help Chrome handle those fields, which should, in turn, help with the search box:
<label for="username">Username</label>
<input type="text" name="username" id="username"
placeholder="Username" required autocomplete="username">
<label for="password">Password</label>
<input type="password" name="password" id="password"
placeholder="Password" required autocomplete="current-password">
This Google dev guide on forms has additional info about adding metadata to your input fields: https://developers.google.com/web/fundamentals/design-and-ux/input/forms/#use_metadata_to_enable_auto-complete
I have an HTML form on a page. The method is POST, but I'm manually adding a GET parameter to the URL string depending on which button the user clicks. But when the form is submitted, the GET is being stripped off the URL.
I'm really baffled by this. This method has worked many times in the past, and this actual form itself used to work fine. Suddenly, the exact same (formerly working) code doesn't work.
I'm using Firefox Web Developer tools to look at which parameters are passed in the request, and there's no sign of the GET.
<form method="post" target="_blank">
<input type="hidden" name="report" value="abc">
...a couple Select form fields...
<input type="submit" action="reports.php?format=PDF" value="Go">
[<input type="submit" action="reports.php?format=preview" value="Web Preview">]
</form>
Basically, if they click "Go" they should get a PDF, and if they click "Web Preview" they get the same report as a web page; but the "format" parameter isn't received on the processing end of things.
(I've also tried it in multiple browsers.)
Edit to add: I can confirm that the POST data is being received on the processing end. Only the GET is missing.
Edit to add:
If I move the action to the <form> tag, it works. Of course that prevents me from having two buttons that do two things, so it doesn't solve the problem, but it's a clue to what might be happening. This DOES work:
<form method="post" action="reports.php?format=PDF" target="_blank">
<input type="hidden" name="report" value="abc">
...a couple Select form fields...
<input type="submit" value="Go">
<!-- [<input type="submit" action="reports.php?format=preview" value="Web Preview">] -->
</form>
The first place I would look would be to verify that the data is indeed being sent as a POST request. If, for any reason, the browser thinks the form should be using a GET request, it will quite happily delete and replace the hardcoded query string.
What I would suggest is doing a var_dump() on $_POST and $_GET in reports.php to get a definitive idea of what the browser is actually transmitting. There may be some clues in the output.
If the $_GET data is truly missing, I would then check to verify that no one has put a rewrite rule into place on the server to strip query strings off of PHP requests, or even requests to this specific page. As far as I am aware IIS does not normally strip query strings from POST requests, as this would go against well established standards, but it is always possible that rules were manually added to accomplish the same thing.
Solved -- In a submit <input>, an "action" attribute is invalid. I should have used "formaction":
<input type="submit" formaction="reports.php?format=PDF" value="Go">
Somewhere along the way an update to various web browsers must have stopped accepting "action".
I've searched through the forum and couldn't find a specific answer on my troubles.
What I want to do, is having a simple form, where a user can input information and then, when a button is pressed, get it saved on the server. And if its possible get the XML document saved with the name that specified in the first field.
I need to pull out the information in an app written in action script. Which is, sad to say, the only language I know properly.
I'm trying to get my information from this form (it should be bigger, but right now, I just need a working example):
<form action="" method="post" class="form">
Name: <input type="text" id="name" name="name">
<br>
Activity: <input type="text" id="activity1" name="activity1">
<br>
Activity: <input type="text" id="activity2" name="activity2">
<input type="submit" id="btnSub" name="btnSub" value="Save">
</form>
To be saved in a XML document.
And as said, everything is going to be on the server. If it helps anything.
I can't use ASP as one.com doesn't support this. :/
Hopefully some of you are able and willing to help me out.
I'll try to answer everything thats unclear.
This may be of help:
http://www.hardcode.nl/subcategory_1/article_431-xml-to-string-and-string-to-xml-in-javascript
You can then use an AJAX call in jQuery to send the data to PHP to save it if that is what you are needing.
EDIT: However, I do feel that it is much easier for this to be done server-side. I'm not great with PHP but it's very simple in .NET (unfortunately you explained you can't use this option).
I need a login form where I just need to provide my username,cause it will remember my password and automatically fill in the password field (Ex. Like in gmail auth).
How could I achieve that?
thanks
Luca
A note for people to avoid banging their heads against the wall: Chrome won't save and suggest passwords on untrusted sites.
As such, if you are testing on your local server at https://localhost, and you haven't generated a valid and trusted certificate, you won't be able to test this feature of Chrome's.
This type of behavior is usually defined by the browser. However there are a few things you can do to improve this behavior.
Make sure you use descriptive names for your form
<label for="username">Username</label><input type="text" name="username" />
<label for="password">Password</label><input type="password" name="password" />
Using these names can really make a difference. I for example use the Opera browser, and in my settings, I've set a few values. For example "name", "address", "telephone number". And opera will look for fields that have equivalent names, and I can let Opera fill it in for me.
The next two things are only supported in Internet Explorer, and I would by no use advice to implement them without thinking about it
I mean, I think it's no harm implementing them. It just gives a little more support to Internet Explorer users, but I wouldn't rely on them
Also Internet Explorer supports an attribute called autocomplete, which you can control whether IO should autocomplete the input. You can use it as following
<input type="text" name="username" autocomplete="on" /> <!--Enabled-->
<input type="text" name="username" autocomplete="off" /> <!--Disabled-->
Also (an IE only feature, I think...) is the support of vCards. You can add an attribute VCARD_NAME and it lets the browser fill in the appropriate vCard value. For example
<input type="text" name="email" VCARD_NAME="vCard.Email" />
Gmail doesn't autofill your password, it is your browser that does this.
What can help is using something like LastPass but you need to leave it to the individual users whether or not they want their password remembered.