1) A typical Login Screen of an application, ID locked for wrong passwords when more than three attempts.
2) The attempt cannot be stored in session, because user might use multiple browsers in same or different machine.
3) I don't want to persist the count in the database since one would have to reset it after 24rs or so.
What is the best way to do this?
You can persist the date of last correct login, date of last wrong login and count of wrong logins in a row.
The "lock" would happen automatically if count exceeds 3 and the last wrong login was in last X minutes. That way you don't have to reset anything just to compare dates ;)
You'd probably want to use IP address to track incorrect login attempts.
If you are looking to see if someone is trying to brute force a password, then use IP.
If you are trying to lock out users who forgot their password, do it by user name.
Related
I am using cucumber in combination with selenium for testing the java web application. The following is the Scenario that we have
get generate PIN page
enter user name
enter password
click on submit button
Now it generates a PIN in the database depending on so many calculations. now i need that particular PIN, to give it as an input to a different scenario. how can i achieve this? Thanks in advance.
I would assume that you can access the PIN within the database after the above scenario. That being the case, I would add one more step to the scenario that acquires - and confirms - that the PIN was indeed generated. At that point, you can store the PIN in a local variable and then use it within the next scenario.
So your first scenario would look like this:
Get generate PIN page
Enter user name
Enter password
Click on submit button
Confirm PIN number in database
The last step would not be done within Selenium, but via an API call or some other means to acquire the PIN from the database. It would confirm the PIN (e.g.; regex=/^\d{4}$/) and then store it in a local variable, say something like #customer_pin (assuming you're using Ruby).
Your next scenario would start off something like this:
Get generate login page
Enter customer ID
Enter customer PIN
etc
When you hit the "Enter customer PIN" step, you pull it from the locally stored variable (#customer_pin).
My advice is that when executing this second scenario, you confirm that you have a legitimate PIN within your locally stored variable, in case someone should run this scenario out of sequence. You could do this by using a global variable and running a "Before" hook in your features/support/env.rb file like this:
Before do
$dunit ||= false
return if $dunit
$customer_pin = nil
$dunit = true
end
In this case, I use $customer_pin instead of #customer_pin in order to make the variable globally accessible. Then after running your first scenario, $customer_pin would be assigned to a legitimate value so that it can be used in any subsequent scenarios. Subsequent scenarios would use the regex expression to confirm it has a legitimate value, and raise/throw an exception if not.
I would divide your problem into two.
One that verifies the pin generation as this may be important for your stakeholders.
One that implement a backdoor to support other cases where a valid PIN is needed. Maybe an API that is able to generate or retrieve a valid pin number. Maybe create and store the PIN in the database without touching the system from the outside. I would use this way to retrieve a PIN whenever I need a valid PIN for other scenarios.
The technical solution on how to get a valid PIN isn't too important. What is important is to decouple the execution order of the scenarios. The execution order of the scenarios is undefined. Each scenario must be able to be executed in isolation and in random order.
Coupling scenarios is a well known anti pattern described here and here.
To Solve this kind of situation you have to use Cucumber Background feature, This is run before each step. and will generate a PIN based on given inputs and then generated PIN will be available across the scenarios.
Find feature file definition based on your requirements.
Background:
Given I Get generate PIN page
Then I Enter user name
And Enter password
And I Click on submit button
And I Confirm PIN number in database
#TC01_GetUserInformationByPinTest #NoBrowser
Scenario: Get User information by generated PIN from background.
Given I Get User Information by using generated PIN
And I verified that given username is same as response Data
I believe this will help you to solve your issue.
I'm having issue with my username, permissions etc. I just checked my password file and noticed my user number / group numbers don't match, they increment by one. is that normal? if not how do i fix? What are the ramifications of each? I'm scared everything will break
user1:x:501:502::/home/user1:/bin/bash
user2:x:502:503::/home/user2:/bin/bash
user3:x:503:504::/home/user3:/bin/bash
The group number need not match the user number. Therefore there is nothing to fix.
Here are three example BDD statements that should help explain my question:
Scenario: User logs in
Given I am on the login screen
When I enter the valid username "myUsername"
And I enter the valid password "myPassword"
And I press the login button
Then I should see the login successful page
Scenario: User buys a product
Given I am logged into the system using username "myUsername" and "myPassword"
When I purchase the product "myProduct"
Then I should have "myProduct" in the product inventory
vs
Scenario: User buys a product
Given I am on the login screen
And I enter the valid username "myUsername"
And I enter the valid password "myPassword"
And I press the login button
When I purchase the product "myProduct"
Then I should have "myProduct" in the product inventory
So scenario 1 above is fine, but which is best out of statement 2 and 3. Statement 2 reads nicely and more concisely. But my step definition for
"Given I am logged into the system using username "myUsername" and "myPassword""
will need to repeat calls to the Page Objects (or equivalent) that scenario 1 called... seems like more dev effort.
So really just wondering if anyone knows which is best practise. I have searched online and found the following document:
http://docs.behat.org/guides/1.gherkin.html
This suggestions scenario 2 is best, but then writes: "Authenticate a user (An exception to the no-interaction recommendation. Things that “happened earlier” are ok)" which kinda lends itself to scenario 3.
Cheers,
Charlie
Here is my review of the scenarios you've written.
Scenario 1
Scenario: User logs in
Given I am on the login screen
When I enter the valid username "myUsername"
And I enter the valid password "myPassword"
And I press the login button
Then I should see the login successful page
Pros : You are correctly using the Given, When and Then statements. In this scenario the Given sets the initial state of the system, the When indicates actions which a user will take and the Then details the assertions made to verify the behaviour of the system.
Cons : Whilst what you have written will work, the problem you have is that this test is brittle. If your company was to mandate that a time-dependent security token also had to be specified during log-in (for example), you'd have to add another step to input this additional field. However if you rewrote this step to be declarative e.g.
Given I am on the login screen
When I submit valid log-in criteria
Then I should see the login successful page
Then if the log-in process was changed, you would only need to alter the code, the scenario would remain the same.
Scenario 2
Scenario: User buys a product
Given I am logged into the system using username "myUsername" and "myPassword"
When I purchase the product "myProduct"
Then I should have "myProduct" in the product inventory
Pros : Same as above.
Cons : Again the test is brittle as it's imperative i.e. you are specifying the exact log-in credentials and a specific product. I'd re-write this as:
Given I am logged into the system
When I purchase a product
Then I should have that product in the product inventory
You can save the product specified in the "When" step in ScenarioContext.Current. You would then be able to re-use this value in your "Then" step to assert that it is present in the product inventory.
Scenario 3
Scenario: User buys a product
Given I am on the login screen
And I enter the valid username "myUsername"
And I enter the valid password "myPassword"
And I press the login button
When I purchase the product "myProduct"
Then I should have "myProduct" in the product inventory
Cons : This is the worst of your scenarios as you are incorrectly using the Given statement. A Given statement should be used to define an initial system state for the test, so in this case "Given I am on the login screen" is a correct use, but "Given I enter the valid username "myUsername"" is an incorrect use. It is incorrect as it is indicating a user action, hence it should be covered by a When. Yes, you can use a Given to perform the same programmatic steps as a When, but it doesn't make it right!
I'd change this scenario to the version I suggested in Scenario 2.
Firstly, there is absolutely nothing in Gherkin that prevents you from writing specifications in any order, you can even produce compound specifications such as
Given ...
When...
Then ...
When ...
Then ...
Given ...
When ...
Then ...
So why would you want to do this?
Well first lets consider a fourth variant of your scenario
Scenario: User logs in and buys a product
Given I am on the login screen
When I enter the valid username "myUsername"
And I enter the valid password "myPassword"
And I press the login button
Then I should see the login successful page
When I purchase the product "myProduct"
Then I should have "myProduct" in the product inventory
This is of course just a compound of 1 and 2. You might have written this because you had finished testing login and wanted to quickly write and test buying a product. You already have the code for the Bindings in scenario one and now simply need to write the bindings for scenario two. You might consider this your simplest pragmatic change, and you will refactor it later. This nothing wrong with it, running the tests could be quicker, but also its not exactly ideal.
Now imagine that due to the nature of your shop you have written many tests that test different buying processes. We could be testing what happens when you add the same item again to your basket, or if you try to buy something out of stock, or different checkout experiences if you want special delivery. In fact your shop is so successful that you need to be really secure on the web and change your login process. Unfortunately you now have those three lines
Given I am on the login screen
When I enter the valid username "myUsername"
And I enter the valid password "myPassword"
repeated throughout your scenarios. If we accidentally break our login process with some bad code, suddenly all of our tests fail. You are presented with a wall of red and can't really narrow down where to start looking at the problems. Because we are dependant on logging in before we run our scenario we cannot isolate login from purchase.
This really is the difference between a Given and a When. A When is there to indicate that we are performing a process, a Given is a means of directly affecting the run time environment so that we simply have the correct state. It's basically the difference between
//Given
isLoggedIn = true
//When
if CheckValidPasswordForUser(user, password)
isLoggedIn = true
The Given has no way to fail.
So coming all the way back to your original question,
Can you re-use Givens as Whens? Yes, but it in the long term it will confuse you.
But if you ask Can you re-use Whens as Givens? then I would definitely advise you not to. This will hide the fact that something that could break is being tested.
Finally there is one other thing to consider and that is the domain of your specification. Dan North has a really good article on this Whose Domain is it anyway?, but the general gist as applied to your example here is that when you are looking at product buying you can simply write
Given I am logged in as a customer
or
Given I am logged in as an administrator
because the username and password parts are to with login and not products, and that way you are protected from re-writing all your scenarios when you change your login process to use something else.
Actually, i have this url http://mydomain.fr/user/1 in my web application. I think it is not very safe
I would hide the id which is auto_increment.
To not be able to do that:
http://mydomain.fr/user/1
http://mydomain.fr/user/2
http://mydomain.fr/user/3
http://mydomain.fr/user/4
http://mydomain.fr/user/[...]
I do not know which technique to use...
Hash MD5 stored beside primary key
UUID / GUID
I use MySQL.
You should restrict access to URLs based on authentication. Just making it 'hard to guess' an ID will not prevent someone from accessing another user's page or, e.g., deleting an unexpected user. Basically, anyone will be able to access any URL unless you provide some access control.
I think generate a random unique string for a user is the best way.
simply use sha1 hash should be ok.
There is no way properly to hide it, you can generate unique ID with a long random hashed string, it's harder to guest. Basically that won't prevent someone to access other's ID.
OP may be concerned with divulging the primary keys because it could leak information into how many of a certain resource exists.
For example, if he is building a web app and someone creates an account and sees a url of domain.fr/user/23 they will know they have created an account on an application with low adoption.
My suggestion would be to either use a GUID value as suggested above or a username that is constrained to be unique.
If you use a GUID, it will look ugly, but make sure to not just use the beginning part as you could greatly increase the chance of collision since the first 60 bits are based on the timestamp.
If you use a unique username, your url would instead look like domain.fr/user/username
I know this is easily done on RoR.
I am in the midst of writing a test suite for a password management page. For the scenarios, the majority should not actually change the password, but some do. I have used the tag #changePassword so that I can optionally run those scenarios or not.
The problem I run into is trying not to write duplicate steps if possible.
Simplified sample scenarios:
#changePassword
Scenario: successful change
Given the Manage Password page is loaded
And a new password is generated
When the old password is entered
And the new password is entered
And the confirm password is entered
And the OK button is clicked
Then the password has changed
Scenario: failed change (missing confirm)
Given the Manage Password page is loaded
And a new password is generated
When the old password is entered
And the new password is entered
And the OK button is clicked
Then the password change fails
The majority of the steps are identical between the two versions, the main variance that I am concerned with is the And a new password is generated step. In the first scenario, I want the new password to be saved as the user's password. In the second scenario I want the new password discarded at the end.
Something like: (psuedo-code)
And /^a new password is generated$/ do
old password = user's password
new password = generate random new password
confirm password = new password
if tag #changePassword is present
user's password is set as the new password
end
end
Is there anyway to make this possible? I can write a second step like And a new password to be saved is generated or something, but for readability and for the non-tech savvy co-workers, using the same step is the better option. (I have found in the past using different phrases to describe similar processes, that to the user accomplishes the exact same thing, has caused confusion. Trying to avoid workplace confusion if possible.)
Side note: Using Cucumber with Ruby (with Watir), if that makes any difference (does it?)
It's an ugly solution, but can you use a tagged hook to set a variable and then an if statement in the method that saves/doesn't save based on the value of that variable?