Currently, if I have <input type="url">, someone adding a URL without the protocol will cause a message to appear, saying "Please enter a URL". Is it possible to assume http://, unless otherwise specified? If that requires the use of Javascript, or something overly complicated, is there a way to keep the url type on the input, without it stopping someone from completing the form?
The implementation of <input type="url"> varies by browser. It can be implemented as a gadget that implies http:// at the start when no protocol part is present, or in some other way.
You can use the attribute value="http://" to specify an initial value, probably helping the user to get the URL syntactically right. But this is suitable for required fields only. Since http:// is not a valid URL (just a prefix), constraint validation will report an error, if the user does not change the initial value – which is fine for a required field, but not for an optional field.
Related
I'm trying to embed a value into the textbox at the USCIS government website to check my application status number. Suppose it's LIN1234. After inspecting the element of the webpage I see that the HTML wrapper for the textbox is:
<input id="receipt_number" name="appReceiptNum" class="form-control textbox initial-focus" maxlength="13" type="text">
I tried opening up this URL with a suffix added on, but to no avail:
https://egov.uscis.gov/casestatus/landing.do?receipt_num=LIN1234
Is there a way to to this?
Before that, you must understand what means adding ?receipt_num=LIN1234 to the url.
When sending a request (By default and in this context) from your browser, it'll be a GET request (see here) where you send as a get argument your receipt number, setting its key to receipt_num.
What is done to this data on the server side, however, is up to itself.
Just understand that unless the server is made to auto-fill the field with that value in case it receives it, it won't do anything except sending some more data.
I think you want to load this page in your browser with auto-filled field.
In that case you should look into extensions for your browser that would do that automatically.
You probably won't be able to embed a value into the textbox... Just because you are sending values by GET (which is what the landing.do?receipt_num=LIN1234 syntax is doing) doesn't mean that they have something set up to process it, so the GET variable will probably not do anything.
You might be able to see how their URLs work ordinarily, what the page URL that you are aiming to land on looks like, and either decode something from that or set a bookmark there. That said, if they are submitting that data via POST (which they probably are, for security reasons), that probably won't work.
I would suggest looking at reputable form-filling plugins for your web browser, if that's an option. That might allow you to work around that.
I want to verify text in HTML5 form validation. For example, when I fill in a field which should take email address only but when user inputs letters instead, the error message shows up, how can I verify that error message? I have been struggling with this for a very long time and your help is much appreciated.
Since HTML5 there are new input type available i.e. email, tel ... By typing something like this in your form:
<input type="email" required />
you get an email field that is validaded through HTML5. It also has the advantage that, when your page is used on a mobile device the keyboard changes i.e. when you have a tel field the keyboard layout changes to a numbers-only keyboard.
Alternatively you can use a pattern to check whether an email address is valid.
<input pattern="\A(?:[a-z0-9!#$%&'*+/=?^_{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_{|}~-]+)*|"(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])*")# (?:(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?|\[(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?|[a-z0-9-]*[a-z0-9]:(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21-\x5a\x53-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])+)\])\z"/> (no guarantee that this is correct
More information on different input types available since HTML5:
http://www.wufoo.com/html5/
http://www.w3.org/TR/html-markup/input.email.html
http://www.regular-expressions.info/email.html
If you want to make absolutely sure that your email is valid I don't think there's a way around using javascript i.e. to check if a country code is actually valid.
I have a form to select images for a gallery, and I want to allow user to select only jpg,gif and png image formats.
And now, for testing, I change extension of a image to .bmp like "image1.bmp", and when I click in my input file to select a image, this "image1.bmp" is hidden, but If I select "show all files", this "image1.bmp" appears, and I can select this "image1.bmp" and send this image in my form. And Im inserting this image with this format on database.
This is normal using accept="image/gif, image/jpg, image/jpeg, image/png"??
Because what I wanted is to block all formats that are not gif,jpg or png.
I have this input file:
<input type="file" name="img[]" multiple="multiple" accept="image/gif, image/jpg, image/jpeg, image/png" />
This is common browser behavior. Browsers that support the accept attribute use it to create an initial file filter, but they do not prevent the user from changing or removing the filter and thereby selecting and submitting any file they like. The purpose of the attribute is to help users select files of appropriate types.
What browsers should do is less clear. HTML 4.01 says that the accept attribute “specifies a comma-separated list of content types that a server processing this form will handle correctly. User agents may use this information to filter out non-conforming files when prompting a user to select files to be sent to the server”. The reference to server-side processing may be misleading. The attribute affects client-side (browser) behavior only. The intent is to say that the attribute value should be written according to what file type(s) are expected from the user; it is more or less self-evident that the server-side form handler should be written so that it is capable of handling the specified type(s).
HTML5 LC is more verbose. It says that the attribute “may be specified to provide user agents with a hint of what file types will be accepted”. It then describes how it could be used by a browser to provide an adequate user interface. It also says: “User agents should prevent the user from selecting files that are not accepted by one (or more) of these tokens.” This might be sensible, but browsers do not actually do that. Even if they did, the attribute would not constitute a security measure of any kind (because a user could edit the form, or write a form of his own, or use a browser that ignores the accept attribute). Its purpose is to protect a normal user from making mistakes, like submitting a file of a type that will be rejected by the server-side handler.
(Browsers interpret the accept attribute value in rather simple way. They work on filename extensions, so if you name a GIF file, or a plain text file, or a binary program file so that its name ends with .png, they will treat it as a PNG image file, instead of inspecting the content of the file. The .bmp extension is problematic, since it commonly means Windows Bitmap, for which there is no registered MIME type; browsers may treat the nonstandard notation image/bmp as corresponding to .bmp.)
You cannot block sending of files. What you can do is to deal with files properly server-side, and there you should not of course rely on filename extensions but detect the types from the file content.
Clearly if you click "show all" can obviously see other files.
Your question is not quite hide or show, but filter at the time of upload, you have two solutions:
1) SERVER-SIDE:
With php (just an example) and regExp:
if (preg_match('#^image\/(png|)$#', $_FILES[$i]['img']['type']) === false) {
echo 'Invalid extension!';
} else {
//Save file
}
2) CLIENTE-SIDE:
With javascript use determinater lib:
https://github.com/rnicholus/determinater
Changing the extension does not change the mimetype of the file. Do the same test with an actual BMP file.
The accept attribute is not widely accepted. Chrome and IE10+ support it. If you're using anything else, like Firefox, Safari, or Opera, it won't work. You can read more here: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Input
This means that like Guilherme suggested, you'll need a client side or server side check. I'd suggest both. Client site will immediately tell an unsuspecting user, while the server side will help filter malicious users. However, beware, there is some debate on how MIME type detection isn't exactly reliable. You can Google around if you want to find out more about that.
What are the benefits (if any) of using type="password" vs. type="text" when creating a form for account creation on a website? Besides a create and confirm, is there a defined best practice?
The obvious reason is, that you can type the password, even if other people are watching the screen. Often i have this situation when i publish my desktop in a presentation, or if i need to give support to other users.
Besides hiding of the characters, the browser (or desktop application) will also prevent copying the content from the password box. This is one possibility less for other applications to misuse the passwords.
I might me wrong but as far as i know the only benefit of using type="password" is that another person can't see what you're typing. But the value behind that is transfered in plain text if you dont use https.
If you use the password type, the text will be hidden by black dots (or * or .) whilst text entries are displayed in plain text.
Also, if you're using forms with passwords, make sure to use HTTP POST as opposed to HTTP GET. Because on the latter, the entries are visible in plain text inside the options section of the URL (see the difference between HTTP GET and HTTP POST there: http://www.w3schools.com/tags/ref_httpmethods.asp).
You can do that by specifying method="post" as an attribute of the <form> tag.
I have the following html code:
<input type="text" value="test value" readonly/>
This input element is non-editable since it has the readonly attribute. But it's still possible to make this field editable by inspecting the element using the Firebug tool in Firefox. Is there any way to make this attribute non-editable?
This is really not possible. Someone will find a way around it because your code is executed on the client. Even if you secured the client (web browser) there is still a way to post back and tamper with read-only fields using a proxy server like Fiddler. You have two choices.
1)Remove the item from the field list and make it a text element. This is only a valid solution if you don't need the information back in the POST.
2) Keep the item read only (or hidden) but check the content has not changed on the server side. This is a best security practice anyway. You should always validate on the server even if you validate on the client. The reason is that people can work aound client side validation. There are different approaches for server side validation according to your back end language. In this case, if you are using PHP or ASP.NET, then you can stick the value in a session variable before you serve the page and check the POSTED value against the session value when the form is submitted.