There is a website that I use regularly that has quite a few log in fields. I'm trying to formulate a link to pre-populate most of them.
The fields in question are formatted like this:
<input id="frm:User" type="text" name="frm:User" autocomplete="off" style="width:80%" />
I've tried using "http://website?frm:User=User&frmGroup=Group" to no avail. Any suggestions?
Thanks!
There exists no standard way to fill in HTML inputs by passing values into the URL's query string. The URL including the query string parameters is sent to the server as a request, and the server generates the HTML as a response. It's completely up to the remote server how to interpret the incoming query parameters and how to generate the HTML.
What is the reason exactly you want the fields for this particular site to be auto filled? Maybe a password manager like lastpass could do the trick for you?
If you are using Google Chrome, this can be done pretty easily with Autofill extension. All you need to do is:
Install Autofill extension.
Open the website page that you want to auto fill input fields. Activate the Autofill extension.
Fill the input fields manually and then save it to a profile.
Click "Generate Autofill Rules". Next time, when you visit this page, the input fields will be filled automatically.
Related
I am working on a project which involves setting up a bunch of dashboards around the office. The plan is to use Screenly on Raspberry Pi 3s, as it seems to fit our needs for the most part at a very low cost. The problem is, some of the webpages that need to be displayed are locked behind a login. Screenly doesn't have a way to get past this, other than passing the login information and the page redirect through the URL itself. I am aware of the potential security issues this could bring, which is why the account we crated for this use can only view (and not edit) very specific pages.
I want to pass login information through a URL in order to login to a website and directly access a specific page on that website. I have had success passing login information in the form of:
https://website.com/dologin.action?username=CapnCrunch&password=Fr00tl00ps&login=Log+in&os_destination=%2Fpages%2Fviewpage.action%3FpageId%58008
This works nicely when the username and password attribute names are always the same, but not when they change on every refresh. Instead of the HTML attributes for the username box remaining the same every time the login page is accessed, they change slightly every time.
For example, these are the HTML attributes for the username upon loading the page for the first time:
<input name="ct100$phUser$txtUser8193" type"text" id="txtUser8193"
class="login_user border-box" placeholder="My Username">
But when I refresh the page, this same bit of HTML code changes to:
<input name="ct100$phUser$txtUser5516" type"text" id="txtUser5516"
class="login_user border-box" placeholder="My Username">
I would love to pass the URL arguments in the form of:
dologin.action?ct100$phUser$txtUserXxXx=CapnCrunch
Where XxXx is just whatever number the page decided to use at that time.
All the solutions I have found online include using external scripts of some kind. The problem is, Screenly only accepts URLs. Using a script would involve either editing Screenly's source code, or using a proxy webpage.
Is there any way to get around the changing attribute name without using external scripts?
Thanks in advance
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.
Hopefully someone will be able to assist.
I am creating an online submission form in HTML, with the ability to add upload an attachment. The resulting data ends up in a Notes / Domino database.
I have managed to get the HTML form working, with the upload button. However, when viewing the received data, instead of having an attachment in the rich text field of the Notes form, I end up with the contents of the attachment. This is fine where it is a text document. However, when it is a Word / Excel doc, it ends up as a load of gibberish.
Can anyone suggest what is wrong ?
Here is my code :
<form method="post" enctype="multipart/form-data" action="/webquote.nsf/gendoc?createdocument" >
Attachment: <Input Type="file" NAME="Attachments" MAXLENGTH=50 ALLOW="text/*" >
Thanks,
Simon
Here are two lines of code from a production database I built a while ago:
<form name="SubmissionForm" id="SubmissionForm" action="/<Computed Value>/AgencySubmission?CreateDocument" method="post" enctype="multipart/form-data">
<input type="file" name="%%File.1">
It works for me. It may not be exactly what you look for, the file is not attached into a Rich Text field, but you can always detach are re-attach it on the server after submission.
I have also built file uploads using jQuery and Ajax, so the page does not have to be reloaded.
The prefered way for this kind of stuff nowadays would be to directly design an xPage. Does that seem doable, or do you have some constraints, like the HTML being designed somewhere else and the integration with Domino later, almost at last resort ?
From the look of your <input> it would look like we are in the later situation.
What's with the "allow" attribute ? I can't find any reference. Did you mean "accept" ? And what about the value of "text/*" ? This could be the source of the giberish, as the browser and/or Domino would interpret the input as text rather than a blob. A value of "multipart/form-data" would perhaps be more appropriate, but no "allow" or "accept" attribute at all works fine too.
For some reasons, Domino being Domino, the "name" attribute of your <input> element must be "%%File.1", in short simply
<input type="file" name="%%File.1">
Your <form> element is spot on.
The last thing to worry about is that your Domino server will see the file comming out of seemingly nowhere and balk with an error 500 "HTTP Web Server: File Upload Not Allowed Exception". You'll need to talk to your Domino admin and have him set the following parameter in the server's notes.ini :
DominoDisableFileUploadChecks=1
Then you're all set.
Hope this helps.
Create a Notes Form (a Form design element), add a File Upload control.
Add a Web Query Save agent (see Form design ouline).
In that agent, get the NotesDocument notessession.documentContext
This will contain the content of your uploaded file, and any other field son your Form, split into Notes items.
You can get the attached file with notesdocument.embeddedobjects to locate all attachments, and/or notesdocument.getAttachment (if you know the filename).
That's perhaps the oldskool way of doing it, but it's tried & tested, and what Domino is expecting you to do.
I've noticed that browsers don't recognize my password field as a potential auto-complete target. I'm assuming this has something to do with the fact that the password field isn't in the original HTML - it's created by my GWT script after the page has loaded.
Is there a way to tell a browser, "hey, here's this form, treat it like usual?" How can I let browsers hook into my app for autofill?
There are some workarounds to get the browser to auto-complete your login like the one described here.
After struggling some time with it I strongly suggest you simply wrap an existing form of your host page (do not generate the inputs with GWT), do a form.submit() on it and have a servlet listen to the request.
I believe that password fields ( tags with type="password") are not auto-filled for fairly obvious security reasons. It doesn't matter that the field is added after page load by your GWT script.
Try mimicking the field in regular HTML and compare that to how your GWT app creates the DOM structure. Perhaps your GWT app is putting the page together differently?
I am working on a login dialog to my site. To spare users the frustration of having to remember their login details, I want to cooperate with the built-in browser password managers. I have worked out that to get Firefox to play ball, I must use a plain-vanilla HTML Form. Fine, so be it. However, I will not transfer unencrypted passwords. So my form content looks like so:
input#1 type="text" name="login"
input#2 type="password"
input#3 type="hidden" name="passwd"
I then intercept the submit and encrypt the content of #2 into #3, and off goes the form. Works a treat in IE and Firefox, not so in Opera and Chrome. Just rifled around SO and find that the problem is input#2, which does not have a "name" attribute. A quick test reveals that when I add name="ignore" it does work indeed in Chrome and Opera. Only trouble is that the password is now sent across the network plain text, with the label "ignore". Thanks a bunch. The whole point of omitting the "name" was to omit that field from the form.
If there a way that I can suppress input#2 from being sent while still giving it a "name"? Or is there another trick I could use?
Thanks.
The answer in the narrowest sense of the original question is: yes, it is possible via Ajax. Create a vanilla FORM with two named INPUTs and submit BUTTON. (Don't forget to feign some action in the FORM attributes.) Now it looks like a plain-text HTML affair. Next in JS, intercept the onsubmit from the FORM and launch an Ajax request to your PHP script, POSTing the plain login and hashed password. Return FALSE from onsubmit to suppress the FORM's action. You're done. No more plain-text passwords across the wire...