when a new client is added I want to verify if the newly added client's details are correct.
For example,
Create a new client, after creation search his name and check if the details are correct or not.
Should I include them both in the same feature, or should I create a different feature for both adding and searching clients
Feature: Creating a new Client
The user is
Able to add a new Client
Scenario: Valid client entry.The client has a username,address
Given User is on the client page
When When he clicks on the add new client
Then He should see a pop up
Then He will enter the client name,address,title,phone no and email
And Click on the save button
Feature: Search for our newly added user
The user will be able to search a client
Scenario: Search for our newly added client
Given User is on the client page
When He click on the client search
And Types the user name
Then He should be able to match the first result
When He clicks on the first matched result
Then It will take him to a page with users details
It would be better to keep them separate. The strategy that worked best for me in many projects are, you should map each feature to the requirement (i.e. the high level user story or the requirement that is given to you from which you derive BDD scenarios and steps). Keeping each high level requirements in a separate feature files increases readability and maintainability.
In this case, looks like "Creating a new client" and "Search for our newly added client" are two different requirements/user stories, it is better to manage them separately, as the scenarios in each of these cases would vary. For an example, "Creating a new client" might have following scenarios:
Scenario 1: Create a valid client entry.The client has a username,address
Scenario 2: Creating a valid client entry failed due to missing information
Scenario 3: Creating a valid client entry failed due to client already exists
And for "Search for our newly added client" you would have other scenarios like:
Scenario 1: Search for a newly added user using username and search result should show the user details
Scenario 2: Search for a user using username who is not in the database and empty search result should be shown
Scenario 3: Search for a newly added user using address details and search result should show the user details
Scenario 4: Search for a user using username using address details who is not in the database and empty search result should be shown
As you can see, each feature is now nicely segregated and have their own related scenarios. As the project grows these scenarios are likely to grow and it would be easier to manage by keeping each high level requirements in a separate feature file.
Also another practice that really worked well for me is to prefix the Jira ticket(or whichever tool you use to manage your user stories) to the feature file as it would be easy to search and manage. For an example, your feature should be like "TI1001 - Creating a new Client" and "TI1002 - Search for our newly added user"
There are lots of ways to do this
features
clients
add_new_client
search_for_clients
I'd favour this one if clients are a really significant part of the
project
features
client_add
client_search
but this one would work.
The important thing is to try and be consistent.
As for your scenarios try and make them simpler e.g.
Feature: Add new clients
Background:
Given I am allowed to add clients
Scenario: Add a client
Given there are no clients
When I add a client
Then there should be a client
You want your happy path scenarios to be this simple, so you can expand on them with sad paths. e.g.
Scenario: Add a new client without an address
Given there are no clients
When I add a client with no address
Then I should see that a client cannot be added without an address
As far as searching goes things can get quite complex so again start simple
Feature: Search for clients
Scenario: Search for client Fred
Given there is a client Fred
When I search clients for Fred
Then I should see client Fred
Scenario: Search for client Fred when Fred does not exist
Given there is a client Sue
And there is not a client Fred
When I search for Fred
Then I should see a not found result
Scenario: Search for clients by postcode
Scenario: ...
With searching you need to be careful not to spend all your time testing your search engine (it should already be well tested.
These sort of features and scenarios are declarative, rather than imperative. They state WHAT they are doing and WHY, but avoid describing HOW anything is done. Cuking is much more effective with a declarative approach.
Related
Say, I want to create an account system. there is a user id, user name, user email and other fields.
I have the following "find_by" scenarios, so I will also have some "find_by" tables such as account_by_name, account_by_email.
When create an account, I need to check whether the name or email has already been used or not.
Considering the restrictions of batch and lwt, how to accomplish the logic above?
Try looking at the KillrVideo example project. You can look at the schema to see how the user tables were modeled, and look at the user DAO code to see how users are created using LWT. KillrVideo also has examples using other programming languages; you will find links to all the github repos on their website.
I am pretty sure my understanding is correct but since I cannot find any Google documentation that explicitly highlights this I wanted to ask here.
Per https://developers.google.com/apps-script/guides/triggers/installable:
Installable triggers always run under the account of the person who created them.
And we know that when you create a trigger it will ask to authorize for all the scopes the script uses.
Then, that means that anyone with edit access to the script could leverage the Google identity of the user used to create the trigger to access the scopes the trigger is authorized for.
For example:
User 1 creates a Google Apps Script that uses GmailApp to send an e-mail
(i.e. GmailApp.sendEmail("one#example.com", "test subject", "email body");)
User 1 creates a trigger to run said script every hour and authorizes it with the appropriate GmailApp scopes
User 1 gives User 2 edit access to said script
Now, User 2 can go into said script and make changes to the code and access User 1's Gmail account. For example, user 2 could change the code to:
var emails = GmailApp.search("search string to find sensitive emails")
// use GmailApp.sendEmail to forward those details to someone else like User 2
All they would have to do is make changes to the code and save; they wouldn't need to re-create the trigger since it already exists. And the next time the trigger runs it would run the newer/updated code.
I was able to confirm this behavior by creating a test script on one of my accounts and giving another account edit access.
So my question is, what is the official/recommended way to mitigate this risk? The obvious answer is to not give anyone else edit access but what if that is not an option -- what if for support purposes multiple people need to be able to access the script, then what?
As you say, the only official/recommend way is to limit editing access to trusted persons.
In your particular example, User 1 could have chosen MailApp instead of GmailApp. The two seemingly redundant services are available separately because MailApp has very limited privledges exposed compared to GmailApp. (For instance, User 2 cannot search the victims Gmail with the MailApp service.)
You can collaborate while avoiding giving direct access to your script file using clasp and git. Only you push with clasp to the script. Everyone else submits changes through git. You can setup the system to be fully automatic (i.e. a git push triggers a clasp push) or manual (i.e. you review all changes first), bit either way you have good records of who did what, when with git.
There's inherent trust when you provide edit access to the script project. You either trust the person or don't trust them. There's no inbetween.
Some "theoretical" ways you may still protect the data:
Create and use different Google accounts.
Install Triggers at the specific deployment/not at Head:
Possible only if done manually. Installable triggers created programmatically can only be used at Head
When you deploy a web-app/api, You can deploy it a specific version.
This deployment version can then be provided, When you create a new trigger for a project here.
There is no need for a working web-app/api. We're only looking to get a deployment id.
In this way, even if user changes the script, your trigger will only run at the old version deployed.
Deployed versions can be seen at Publish> Deploy from manifest.
As the previous answer states, git would be a better call.
For all practical purposes, any data you share with a malicious entity should be considered compromised.
I want to make an app where people can text (sms) their name to sign a petition and then their name would be added to a list of signees on a website for the petition.
The sms messages would be handled by Twilio and then be processed by a Node.js app. I would like to use Angular on the front end.
Question: What would be the best way to store the names? Do I need something like MongoDB or would a database be overkill? I'd also like to verify that only one name per phone number is entered.
If you don't use a database you'll need to store it in memory. This will mean when you restart the server or it reboots you will lose your names.
So the short answer is yes you will need a database.
As for checking if there are duplicates there are many method with mongodb.
You can use a find query first to check that it does not exist already.
You could use upsert which will replace a previous one matching one.
However you can use any type of database that you wish.
I'd like to vote in favor of a relational database, probably it's a good fit for your kind of project.
Take in account that you can also store some interesting fields that comes with the Twilio request like country and state to list some.
You can take a look at this tutorial where not only you can get the SMS but reply to the user to have a smooth user experience in the process: https://www.twilio.com/docs/sms/tutorials/how-to-receive-and-reply-node-js
before write the question sorry for my english. My question is this:
I have an web application in jsf, the application have new, edit and delete Categories, outgoings, Budgets, users, etc.
When open the edit page i have the url like this:
http://localhost:8080/Practica3/faces/usuarios/edit.xhtml?id=2
the problem is if the user change the number 2 for another number, and the another number exists in the dababase, the page change the data of the id 2 to the data of the new id.
The problem is if the id number X is of a data of another user, and the user that change the id is not in conditions to see that data.
How disable the edit of the id, or denied to show the data to the another user?
Thanks, and i hope have a response.
Just check in service layer if the current user is allowed to edit the requested entity. If not, then throw some security exception for which you could if necessary configure a custom error page in web.xml.
The technical problem has nothing to do with HTTP/JSF. If you "fix" it alone in JSF side, then you still have a gaping security hole in service layer which would affect any other frontend using it. The frontend is not responsible for business restrictions in service layer itself.
The problem is not stopping the editing of the ID. That is on the client side/browser and you cannot stop this value from being edited.
You need to implement propery Access Security Controls. When you get any response back, you need to check if the user can perform the action they specified (read, update, delete, etc.) as well as checking to make sure they have permission to the data they want to perform the action on.
These two topics are on the OWASP Top 10:
A4-Insecure Direct Object References
A7-Missing Function Level Access Control
The pages will tell you what the problem is, mitigation stragegies, and different ways of testing for that in your application.
I would also become familiar with the other Top 10 categories (this is not an all inclusive list but a good starting point).
Hello I'm developing a web app where the user needs to verify that they are the "Owner" of the website. I know there is code verification but how would I check if that verification is on their site without over complicating the verification method?
Also, I'm thinking about giving the site owner an hour to verify, how would I automatically detect if the hour is over and be able to delete them from the database?
The way Google or Yahoo do this is to require the webmaster to create a file with a special cryptic name (the file length can be 0), which is generated by Google/Yahoo. Could be something like "dsaa6fd4sgfdsf324gd.html". So you generate such a unique (name) string for each websit eto be verified, store it in the DB, and then you go and try to GET it from that site. If the GET succeeds you can set "verified=true" in the DB for that site and file name.
To answer the 1hr question we'd have to know what technology you are using. There are many options to run timed background jobs from a web application. Usually you write the job details into the database, and have a background daemon check the DB periodically and execute any pending jobs. You could tell it (that daemon) to execute a job one hour later to see if the file (see above) exists. Well, you have to do it that way in any case, it's no use simultaneously telling the webmaster to create that file and check for it right away :)