I'd like to using protractor script to verify given password is hidden not in clear text. However
element.getAttribute('value')
returns the clear text.
My questions:
Is it possible to verify the hidden password with help of a protractor script?
If yes, what is the correct function or what are the correct
functions?
The main difference between a normal text field and password field is their type attribute. For normal text field, the value of type attribute is <input type='text'> and for password field <input type='password'>. So using protractor it can be verified using below code.
var passwordField = element(by.name("pass"));
expect(passwordField.getAttribute("type")).toEqual("password");
Related
I have an ordinary sl-input in a form on a page
<sl-input name="email" type="email" placeholder="Email address"></sl-input>
I want to change the name property of the sl-input using JavaScript.
document.querySelector('sl-input').name = "new-email"
The above code seems to change the name property of the input field in the shadow DOM, but the sl-input's name property remains unchanged. If I then submit the form, the payload data refers to email, not new-email.
How can I change the name property of an sl-input using JavaScript?
The name attribute can be updated using setAttribute.
document.querySelector("sl-input").setAttribute("name", "new-email")
I'm using Capybara with Cucumber.
The webpage I'm testing contains many email fields throughout but the ID's and labels for the input field change depending on which page you're on.
What I'm trying to do is create an generic reference to any email field so that one fill in method will work for all pages.
When inspecting the input fields, I can see they are of type='email
The full html:
<input id="privatekeeper_email_email" name="privatekeeper_email.email" value="" data-validity-message="Must be a valid email address" no_optional_label="true" type="email" autocomplete="off" maxlength="254">
In my block below you should be able to grasp what I'm tring to do:
email_fields = all('input[type="email"]')
fill_in(email_fields[0], with: text)
fill_in(email_fields[1], with: text)
end
When I run this, I get the following error:
Capybara::ElementNotFound: Unable to find field #<Capybara::Node::Element tag="input" path="/html/body/div[3]/div/div[2]/form/div/div[2]/div[6]/div/div[2]/div/div/div/div[2]/input">
Reading the Capybara docs, I can see that fill_in responds to ID, name or Label so my reference might not work. Is there anyway I could get this block to work?
Like I said, the Id's and labels are not consistent throughout the user journey
Since you've already found the element you need to call #set on it instead of using fill_in
email_fields[0].set(text)
I'm brand new to Watir. I'm using SafariWatir on a fully updated MBP Snow Leopard.
So far I've successfully used
goto, link, text_field, and button
but when I try to access a text_field with
type="password" name="pass" id="pass"
(as seen in Web Inspector) with
browser.text_field(:id, "pass") or
browser.text_field(:name, "pass")
I get
Watir::Exception::UnknownObjectException: Unable to locate TextField
There's a very simple answer:
In Watir and FireWatir, a password field is called
text_field
In SafariWatir, a password field is called
password
So, to access a input of type=password, I needed to use
browser.password(:id, "pass")
or
browser.password(:name, "pass")
This solved my problem.
Notes: I'm using mac 10.8,ruby 1.9.3;
The working sample is: browser.password(:name,'password').set'yourpassword'
There is no space between set and the value.
I used set to insert a value in a text field under a div.
Below is the approach that I've used without success. This is the only way I was able to identify the element. When I tried to identify text field by name was not recognized.
#browser.div(:evaluation, :id => "evaluation_form_attributes").text_field(:id => "evaluation_form_name")
#browser.set('Teacher Evaluation Form')
The following error was displayed:
undefined method `set' for #<Watir::IE:0x4dd9348>
This is the HTML:
div id="evaluation_form_attributes"
Evaluation name:
input id="evaluation_form_name" type="text" size="50" name="evaluation_form[name]" maxlength="30"
Try this:
browser.text_field(:id => "evaluation_form_name").set 'Teacher Evaluation Form'
Is there an iframe involved perhaps? if you know the thing is there, and you are sure of the ID, and watir cannot locate it, then usually it's because that part of the page is inside of a frame.
To work with elements that are inside of a frame, you must specify the frame, then the element
browser.frame(:how, what).element(:how, what).method etc.
see http://wiki.openqa.org/display/WTR/Frames for more info
To set a value for a text field you simply need to find it and set it. The setting part you already know (set), so you need to string together something that finds the text field.
if Zejiko's answer doesn't work because of "unable to locate element" then it's not the setting that's failing, it's finding the text field. Use Firebug (in Firefox) or some kind of DOM toolkit (Tools>Developer Tools or F12 in IE8) to find the text field and see what kind of attributes it has.
Ensure the id is really "evaluation_form_name". This is case sensitive and sensitive to leading/trailing spaces. You could try the following to make your search broader:
#browser.text_field(:id => /evaluation/).set 'Teacher Evaluation Form'
This uses a regular expression to identify the id. You can search by many things, not just :id, and you can use more than one. For example:
#browser.text_field(:id => /eval/, :index => 2)
finds the second text field whose id contains "eval".
What you can use to identify the text field can be found here: https://github.com/watir/watir/wiki/HTML-Elements-Supported-by-Watir
Using Microsoft's AntiXssLibrary, how do you handle input that needs to be edited later?
For example:
User enters:
<i>title</i>
Saved to the database as:
<i>title</i>
On an edit page, in a text box it displays something like:
<i>title</i> because I've encoded it before displaying in the text box.
User doesn't like that.
Is it ok not to encode when writing to an input control?
Update:
I'm still trying to figure this out. The answers below seem to say to decode the string before displaying, but wouldn't that allow for XSS attacks?
The one user who said that decoding the string in an input field value is ok was downvoted.
Looks like you're encoding it more than once. In ASP.NET, using Microsoft's AntiXss Library you can use the HtmlAttributeEncode method to encode untrusted input:
<input type="text" value="<%= AntiXss.HtmlAttributeEncode("<i>title</i>") %>" />
This results in
<input type="text" value="<i>title</i>" /> in the rendered page's markup and is correctly displayed as <i>title</i> in the input box.
Your problem appears to be double-encoding; the HTML needs to be escaped once (so it can be inserted into the HTML on the page without issue), but twice leads to the encoded version appearing literally.
You can call HTTPUtility.HTMLDecode(MyString) to get the text back to the unencoded form.
If you are allowing users to enter HTML that will then be rendered on the site, you need to do more than just Encode and Decode it.
Using AntiXss prevents attacks by converting script and markup to text. It does not do anything to "clean" markup that will be rendered directly. You're going to have to manually remove script tags, etc. from the user's input to be fully protected in that scenario.
You'll need to strip out script tags as well as JavaScript attributes on legal elements. For example, an attacker could inject malicious code into the onclick or onmouseover attributes.
Yes, the code inside input boxes is safe from scripting attacks and does not need to be encoded.