I am trying to learn BDD cucumber and i am trying to write a feature file for login scenario with valid and invalid usernames.
For valid user will be logged and will logout however for invalid username, the user will be asked to go to login page again and asked to write correct credentials.
I would like to ask, can we have both positive and negative scenarios in "Scenario Outline"?
Could you please help me in writing perfect feature file for this simple scenario?
Take a look at my feature file code ( PS, I am a beginner :))
Feature: Login Action
Description: This feature will test a LogIn and LogOut functionality
Scenario Outline: Login with valid and Invalid Credentials
Given User is on Home Page
When User navigate to Login Page
Then User enters "<username>" and "<password>"
And Keeping case as Valid
Then User should get logged in
And Message displayed Login Successfully
Then User enters "<username>" and "<password>"
And Keeping case as InValid
Then user will be asked to go back to login page
And Provide correct credentials
Examples:
|username|password|Case|
|abc#gmail.com|12345|Valid|
|abc1#gmail.com|dfsd2|InValid|
Scenario: Successful logout from application
When user logs out from application
Then Message displayed Logout successfully
And Browser quit by driver
'Perfect' - Ain't no such thing...
The ScenarioOutline you have written is very confusing and possibly a wrong interpretation of how scenariooutline works. Basically you are logging in twice with each row of the examples table ie. same username and password (line 3 and 7 in the SO). In a scenariooutline all the steps will be repeated with each row of data that u provide in examples. Refer to multiple tutorials available.
Why mix up valid and invalid logins? Keep them in separate scenarios. Easy to follow.
Move the logout to a separate feature file.
Then you can move the first 3 steps of the login scenario into a background. Reduces repetition.
You are going to have a problem with checking login functionality for the valid case for multiple data. Once a valid user logs in then most web applications store the login credentials in a cookie etc etc. So when a new request is made for login page it might just skip the login page and land up in maybe lets say home page. Then you will get the NoSuchElementException when the selenium code looks for the userid input box. So for valid cases you need to have a logout too.
#Login
Scenario Outline: Login with valid and Invalid Credentials
Given User is on Home Page
....
....
#Valid
Examples:
|username|password|Case|
|abc#gmail.com|12345|Valid|
#InValid
Examples:
|username|password|Case|
|abc#gmail.com|12345|Valid|
To run the Valid Login cases use the tags option in runner as {"#Login","#Valid"} or if on cucumber 2 #Login and #Valid. For Invalid one replace with #InValid.
As pointed out here in an excellent answer - each scenario is essentially one test case and must therefore be clearly separated.
Nevertheless, it's critical to understand that Given/When/Then (in their most basic essence) are equivalent to the traditional three stages of a system test: Arrange/Act/Assert, therefore:
Given: Arrange the system in a known state
When: Command the system (what you want to test)
Then: Assert that the outcome was what you expected.
That's it! (of course there's a lot more to BDD than that - but these are the basics of an executable specification)
Given User is on Home Page is not arranging the system in a known state, but Given I am registered is. Though it might not be enough to state just this, because as soon as you go through the whys and whats of the scenario you'll quickly realize that you're missing something more concrete as an example.
To paraphrase the previous answer:
Given I am registered -> set up the user (but does it matter who?) as being registered in the system (database entry?), registered for what? does it matter to the outcome?
When I sign in -> Give the system the command to sign-in (who?) - this might be done via a web form or via an API (or over the phone?). Does it matter what time you sign in, can you sign in immediately?
Then I should be signed in -> Check response from web app, database, session? cookie?
Saying that, logging in scenarios are probably not worth using BDD to tackle since they are as well defined as CRUD - there's almost no need for analysis.
Scenario: Good sign in
Given I am registered
When I sign in
Then I should be signed in
Scenario: Not registered sign in
Given I am not registered
When I sign
Then I should not be signed in
And ...
Scenario: Registered with wrong password
Given I am registered
When I sign in with a bad password
Then I should not be signed in
And ...
Tips:
Keep things simple
Don't use outlines
Keep details of HOW you do things out of scenarios
Have one scenario for each path
10 simple scenarios are better than one complex one.
You can see details of how to write scenarios like this (in Ruby) at https://github.com/diabolo/cuke_up/tree/master/features.
Caveats:
this is just one persons opinion
you need to be able to write code to work this way (as you push all the details of how things are done out of cucumber and into helper code).
registration is a pre-requisite to sign in
Related
On my signup page i want to check if a certain user with the an email that i specify exists or not. I did try the approach on the answer given to this question (react native firebase check if user already exisits in real time database) but i get an error when i try to do that
I am aware that when you are doing firebase.auth().createUserWithEmailAndPassword it tells you weather user already exists or not, but for reasons that are complicated to explain, i dont want to do that for the time being. I do, however, have access to the config
If the create user func is done on a different page from where the actual form its-self is, then the options are:
Query the results as seen in the link above, given you fix the error
Use Firebase Admin SDK (the better option in my opinion), which gives you access to a number of useful functions, which won't require a form, one of which is:
admin.auth.getUserByEmail(email)
There are several functions that will get you the information you need.
Here is a guide for adding the Admin SDK to your project (should you wish): https://firebase.google.com/docs/admin/setup
In the firebase console you can already set it up under Authentication -> Sign-in method tab and scroll down to the bottom you will see Advanced and set 'One account per email address'
I did read every article on the first page of google search. At best, there's something vague like it removes script tags and other harmful content. Is that basically all it does? What is this "other harmful content"?
What's the end goal here, what's my concern?
What is this normally even used for? Is it reasonable to use it if we let a user enter a long string that might contain html? Or is it only for when we are explicitly letting the user generate html?
For example's sake, Alice might have an SPA in where she lets her users type in code snippets that are also executed in the same page, which are also shown to other users who visit the page as well.
Bob decided to insert a malicious snippet that let him get information on those who view those pages, via putting in an HTTP request to his own end with the viewer's credentials, i.e account username and session ID in the frontend, or an external script that does the same.
Alice viewed the page, after all she's curious on what her users have been doing! Little did she know that Bob now has access to her session ID with elevated privileges.
Bob then continues on to access the app with the said session ID, elevates his own account to Administrator privileges, kicks out Alice's account and helps himself to the information inside... possibly credit card account details. I'm just weaving on the spot but you get the idea.
In a nutshell you shouldn't trust all user input when you're letting them render it. That is what ngSanitize for, to keep you from unwanted code execution.
I have created a web page with RoR and i am using auth system that i wrote. Now i would like to create an admin panel, where i can see the user info etc..
I am not sure but what i though is to add a column name to auth system like admin? giving a default name false. Then if the admin? is true admin panel opens instead of the web page login.
I wonder if i can use the same auth system so in order to login to page it logs in to admin panel.
But in the controller it will check if admin? is true for every user, i am not sure about the burden in terms of the system requirments as it will check every user.
And i know there are other gems for admin panel but its fine i can design it. I am just not sure which way is the efficient way.
The burden on the system will be negligible. It depends a little bit upon how your auth system is configured, but I am assuming that you give the user a token when he/she is properly logged in.
When the user first tries to sign in, you should check if they are an admin. At this point, if they are, then you can sign them in as an admin, also storing that information in the session. You should perform this check on the controller actions where they need to be an admin. It will not affect performance to any noticeable degree and is important for the security of your site.
Also, you may want to check out the CanCanCan gem, which is a fork of CanCan built by Ryan Bates, for an example of how this works. Unless you're building the application for educational purposes, I highly recommend the CanCanCan gem.
Hope this helps!
In addition to that, you may try Rails_Admin, which provides an easy-to-use interface for managing your data.
And I've considered to use this gem for my project, which is a huge database, so it seems to very helpful.
I'm playing with the oauth2client.appengine Oauth2Decorator and it interjects it's own screen asking for an email address:
The URL is http://127.0.0.1:8080/_ah/login?continue=http%3A//127.0.0.1%3A8080/mypage
I'm guessing that its intention is to mock being different users during development? But that leaves some questions:
Does it only appear on the dev server?
Do I have to do anything to make it go away when deploying to production, or is that magic?
How do I turn it off for development?
What does it actually do?
if the user is being redirected to an oauth consent page nonetheless what's the point of this?
As you can see I just don't get it. I do see that it gives my get_current_user() a result - a user instance with the email address that I submit.
I recognise that this is effectively the same question as
"How to Bypass Local Login Screen with Oauth2 and GAE", which seems to conclude that the whole oauth2client library is fairly useless and it is best that we all go off and write own authentication flows? Seriously?
If that's the state of things alternative suggestions are welcome (in the comments). My workflow is to send the user off to be granted permissions via Google's Oauth so my webapp can proceed to do stuff on their behalf.
If you want to use the get_current_user() that is provided by Google you can't really avoid it and it is actually something very useful. If you want to do your own authentication stuff then just don't use it and you won't be redirected to /_ah/login.
In short this is just to simulate locally the actual Google Login. It would be a huge mess to login to your actual account while on development mode and it will be really hard to simulate multiple users. That code is not executed online and instead you are being redirected to Google for approval.
i am working on a cakephp 2.x. i am using auth component .. i want to ask if that possible in auth component to track the user fail login attempts and also i have searched on google and i found this component
http://bakery.cakephp.org/articles/aep_/2006/11/04/brute-force-protection
should i use this in my cakephp 2.3 .is that component is compatible for 2.3 ?i want to prevent my app from brute force attact. so is this component is perfect for me ? or if there is any else good component there too or a better approach to handle the brute force?
No, that is a bad approach IMO.
First use blowfish or some sort of hashing with "slow encryption". That is the most important base factor.
Then don't use Session, IP or other easily spoofable data to secure your login, but the actual user record the user wants to login as. This way the attacker cannot influence the amount of login attempts by changing his IP or other identification features. It also protects better against bot net attacks (using multiple computers at once).
So if he tries to login as "carl", count the logins made to this specific account and black hole if too many requests are made within a specific time (temporary disable login for this account). He can still run through all users this way, of course, but he will never ever be able to actually brute force the user.
You should "enable login" for this user again, though, after a specific period of time.