So I've read through a bunch of other similar questions but I'm at a loss as to what I can do.
I have an input box that takes a currency so I'd assume clients would put $2.50 in. I'd also like to have the num keyboard display when a user clicks on it. However if I use type="number" it allows the entry of $ but the event no longer has that content in it and hence I cannot validate it.
I thought about using the keypress function, and although there isn't a value I could convert the code but this seems overkill.
I've tried putting novalidate on the form but it doesn't seem to do anything. I've also seen an attribute event.target.willValidate that I thought could be doing something as it's always true but no validate doesn't seem to affect it.
I've also seen one solution that flicks it between text and number to show the correct keyboard but turn off the validation. This also seems a bad work around.
Anything else I could try?
Related
I'm working on a TamperMonkey script to automate a few things for me on a webpage.
On this webpage there is also an input-field which is giving me some headaches.
I can enter values in the field, but it doesn't get validated and the submit button remains disabled.
I can select the input programmatically by using
elmtsInputs[0].select();
after which I can enter the value from my keyboard without any problem.
However if I try:
elmtsInputs[0].value = "0.5";
The value 0.5 appears briefly before it's being reset again to the default 0.0
So there is some sort of validation happening on the input-field that notices that the value wasn't typed.
Also when I type in an unauthorized value (basically any value greater than 1) it also shows a validation message to say the value is incorrect. So there is definitely validation happening.
I have tried multiple dispatchEvents but none of them worked.
After searching online I came across multiple sources that the problem is related to the isTrusted:false
issue where input coming from scripts are not trusted but keyboard input is.
When trying to look if there was any way to bypass this, I found some examples where the use of the Chrome Debugger was used a solution.
chrome.debugger.attach(target, "1.2", function() {
chrome.debugger.sendCommand(target, "Input.dispatchMouseEvent", arguments)
})
However, I haven't found any useable example on how to implement this.
Can someone shed some light on how this should be implemented?
Thank you.
I'm not sure if this is a cefsharp issue or just Javascript one, but when testing filling in a form on a test site i'm coming across this:
When cefsharp is filling in the fields, it's placing the values over the text instead of inside the input field.
document.getElementsByName('email')[0].value = 'test#test.com';
So after reading (i'm sure it's a focus issue) i tried:
document.getElementsByName('email')[0].focus();
Which should have worked by all accounts, but it never showed any difference from the image above.
I even tried:
document.querySelector("//*[#id="email"]").click();
The xpath to the field, still no difference.
Is it some how needing set from a cefsharp point of view? any tips in the right direction would be great.
As you may know, Chrome does not support:autocomplete="off", autocomplete="nope", autocomplete="false" or even autocomplete="new-password" any longer.
That means, from time to time, I do get reports that honeypot traps are preventing users from submitting forms, since the trap input is being auto-filled, even if not shown.
The practice for setting the trap is wrapping a TEXT input with a display:none; element, so spam bots won't be able to figure its really hidden (unless they are smarter and they usually aren't), and if this input has contents, you won't allow the submission to go through, as the field supposed to be hidden and empty for regular users.
What's your practice in using honeypot traps while still having browsers ignoring the demand for auto-complete or auto-fill by using the above arributes?
My current solution (October 2022) for a honeypot field looks like this:
Move the input field out of the visible area using css
Avoid name attributes that Chrome looks for when autofilling, like email, address, etc.
Do not wrap the honeypot input element with other elements that contain such keywords in their label or in name attribute
If you are using FormFind (which analyzes a page's source code and extracts the 'action' parameter and the input tags will find hidden fields. Hidden fields will not stop a spambot.
FormFind will find all the fields on a form from the HTML source code. And once you find the input fields - and the 'action' parameter (which FormFind does find) - its easy to use CURL or WGET to 'submit' the form.
Although reCAPTCHA will help with spambots, the only technique that I have found (and what I use in my solution) is to have some JavaScript code that will change the form's action parameter on a onclick/onfocus event. And if you put a delay in the JS function that changes the action parameter, that's a bonus spambot blocker.
Using JS to change things (or even to fill in a hidden field, if you insist on using one) is a good technique. CUSL and WGET cannot process JS code. (There was an open source project that claimed to be able to process JS code, but it was abandoned a couple of years ago.)
The JS trick is what I use in my contact form at my free FormSpammerTrap.com site. Code is free and open source. And the contact form there uses my technique. Have not gotten any spam via a spambot (automated process) from there. And I am working on a newer version that will add delays to even further block spammers.
Anyone is welcome to request the code to try it out. No charge. No fees. No advertising. No $$ benefit to me, other than how I use it on my sites to block spam.
So, using hidden fields to stop spambots is not going to work well. You have to have more layers of defense against them. Using JS code techniques is another layer that will help block almost all spambots. (There's no 100% solution, but I think mine is close - and it's been around for a couple of years.)
I removed the name variable from the input tag and this resolved the issue of the hidden honey pot fields getting autofilled...
I have a form with a read only field for display/submit to the next page purposes.
However, I noticed using developer tools in Chrome, I was able to add an id to an element, use the javascript console to select that element, and change its value. I submitted the form and what do you know - the next page acted on it as if it was the original value.
Now, there shouldn't be any problem with the people using the site I'm building, but it seems like a huge security flaw to me. Isn't the point of read-only to remain constant? If a savvy user to change it around, doesn't that pose a big problem? In fact, I didn't even think you could add and change attributes in chrome.
Please post your thoughts below, and let me know if there's a solution ("disabled" textfield, but setting the disabled property doesn't send the data to the next page).
NEVER trust input from a web form.
The user could, just as easily, remove the readonly attribute and edit the value. The readonly attribute is only something to help the user when filling out the form, so they don't edit a value expecting it to change, when your server actually won't let it be changed. So, always remember to code the behavior on your server first, and have the HTML form be a helpful guide for users to make the form easier to fill out (without having to submit the form several times to get relevant error messages).
To overcome this, if something is readonly and you do not want it edited, you could store the value in your database. Also, values provided by users should always be checked (and sanitized) as no amount of JavaScript, HTML, or CSS is going to prevent someone who knows what they're doing from adding new or changing/removing existing values.
I have a script in a web application of mine which forces users to type only numbers into certain text fields. However, when the appropriate text field is selected, the script blocks ANY keyboard input other than number keys and tab. I don't want to limit the user from being able to use their browser's or my app's keyboard shortcuts just because they are typing in a numerical field. (Also, I'd rather not just validate the field instead of preventing number input, my app updates the page based on the numerical input live, so it wouldn't be as nice.)
Can someone please help write/find a little script for me? A simple variation of these numbers-only scripts that can be overrided when a modifier key is pressed is enough (and I guess the overrided character would have to be deleted, too).
I'm not going to write a script for you, but I'll give you some pseudo-pseudo-code:
input = input.replace(/\D/, '');
Try YAV, Javascript validator library.
I think you need mask feature.
Look at field Custom: from this example
http://yav.sourceforge.net/en/example_7.html