From d05986d96abef7ee207f71d9e12a1c13a728468a Mon Sep 17 00:00:00 2001 From: Hidalgo Date: Tue, 3 Nov 2020 13:08:14 -0600 Subject: [PATCH 1/5] new backend challenge draft --- back_end/README.md | 84 ++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 77 insertions(+), 7 deletions(-) diff --git a/back_end/README.md b/back_end/README.md index ea0f96e..e4ae6b4 100644 --- a/back_end/README.md +++ b/back_end/README.md @@ -4,18 +4,88 @@ The following project is to build a simple service that leverages some of the te If any special requirements have been conveyed to you from your interview team, they supercede the following: -## Requirements +## Technical Requirements -- [ ] Create a webservice using Java, Ruby, or Node.js that has a single endpoint. -- [ ] The endpoint should receive a URL as a parameter and return a shortened URL. For example, if the endpoint is given the following URL: "https://facebook.com", it should return "https://hostname/Ux26Yp". -- [ ] When someone accesses the shortened URL ("https://hostname/Ux26Yp"), the server should redirect to the real URL ("https://facebook.com"). -- [ ] Add another endpoint to your service that allows for the bulk (hundreds) submission of URLs. -- [ ] Your submission should contain a README file that spells out the exact steps necessary to build and run the project. It should also provide instructions for how to query the webservice. +- [ ] You can select the language you think is the best for this challenge. If you decide to use a functional programming like elixir just let us know first. +- [ ] You are free to add any library that improve the development experience. Like, linters, formatters, etc.Try to emulate the environment that you would like to have when you are working. +- [ ] You should design your APi for evolvability. Given that in real life no API stays static for long. +- [ ] You can use any API paradigm. Rest, RPC or GraphQL depending on what you think is best for the challenge. +- [ ] The app should have the tests that you decide are necessary for maintainability +- [ ] You should handle all success and errors the endpoints could have. When there is an error the backend should notify the client about it in such a way that allows the client side to decide what to do. (Ex. If the client tries to create an article without a title we expect the API to notify the user that the title is a required attribute in order to create an article) +- [ ] There should be a way for your user to discover how to use the API. It can be a document, postman, swagger or a plain html website. Is up to you but it should allow the user to discover all your endpoints, and their possible responses (success and error) + +## API Specification + +We want to create an API that allow us to handle articles that could be shown in many clients like mobile apps, websites and text to speech apps, etc. + + An article commonly follows this process. + +-> draft -> published + +## Actors + +### Visitor +Is any person that wants to read the articles published in the API. It doesn't have to authenticate herself to do it. + +### Writer +Is a person that have the permission to create new articles in our API. It has to authenticate herself in order to create, edit and publish articles. + +## User Stories + +- [ ] As a writer I should be able to create an article in draft state +- [ ] As a writer I should be able to publish a draft article +- [ ] As a writer I should be able to move an article from publish state to draft state +- [ ] As a writer I should be able to edit any of my articles +- [ ] As a writer I should be able to list all my articles (published and in draft state) +- [ ] As a writer I should be able to see only my draft articles or only my published articles +- [ ] As a writer I should be able to see one of my draft articles +- [ ] As a writer I should be able to do everything a visitor can do in the API +- [ ] As a visitor I should be able to list all the published articles order by published date in descending order +- [ ] As a visitor I should be able to see a published article + +## Bonus Points + +Take 1 or 2, we don't expect for you to do everyone of them. + +- [ ] Update the list of user stories, and the API documentation if we add a new actor called Admin that is the only one with the permission to publish articles but only when an article is "ready to review". Think about how that new actor will change your current implementation and what changes you will need to do. + - [ ] Deploy the API in a Platform as a Service (Heroku, Blue Ocean, AWS, GCloud, etc) +- [ ] Dockerize the development environment so the database, programming language version, etc lives in a container. The idea is that when a new developer starts on the project she will not have to configure the development environment by hand. +- [ ] Write down every tool or methodology that you know for improving backend developer happiness explaining why you think they are necessary. +- [ ] Create a deployment pipeline that runs linters, tests, ect every time any branch is push it to the repository. In addition, when a PR is merged to master(main) branch then the app should be deployed. +- [ ] Write down the name of the strategies or, a little paragraph explaining how you would prevent all or some of these security vulnerabilities. + - Distributed Denial-of Service attacks + - Cross Site Request Forgery attacks + - Man in the middle attacks + - SQL Injection attacks + - Lack of Resources & Rate Limiting + or other possible security considerations. write strategies we could use to prevent it. + + +### Writer +- [ ] A writer should be able to create an article in a draft state +- [ ] A writer should be able to publish a draft +- [ ] A writer should be able to list all her draft articles +- [ ] A writer should be able to see her draft article +- [ ] A writer should be able to delete any of her draft articles +### Visitor +- [ ] A visitor should be able to see a list of all published articles ordered in descending order by published date +- [ ] A visitor should be able to list a published article +### Admin +- [ ] An admin should be able to publish an article +- [ ] An admin should be able to list all draft articles +- [ ] An admin should be able to see any article in the platform +- [ ] An admin should be able to delete an article -Design of the API endpoint including paths, structure, and format is up to you. Decisions on how to structure the code and what frameworks to use are up to you as well. ## Bonus - [ ] Build a frontend for the service in any frontend framework that allows users to submit a URL to shorten it in a form, and see the result. - [ ] Extend your frontend to allow a text file full of URLs to be submitted to the bulk API. Results can be rendered directly on the page or downloaded as a text file. - [ ] Add a view to list all the URLs and their short versions. + +## Things to grade + +- Extensibility of the API +- How easy is for your clients to implement the API +- Error handling +- Api Design From aef376cc2b762bffd52124292fa85aeb2a8c286b Mon Sep 17 00:00:00 2001 From: Hidalgo Date: Tue, 3 Nov 2020 16:36:54 -0600 Subject: [PATCH 2/5] add more user stories --- back_end/README.md | 87 +++++++++++++++++++++------------------------- 1 file changed, 40 insertions(+), 47 deletions(-) diff --git a/back_end/README.md b/back_end/README.md index e4ae6b4..de8a9b3 100644 --- a/back_end/README.md +++ b/back_end/README.md @@ -1,26 +1,25 @@ # Backend Project -The following project is to build a simple service that leverages some of the technologies that we use as part of our reference architecture. +The following project is to build a simple service leveraging API best practices. -If any special requirements have been conveyed to you from your interview team, they supercede the following: +If any special requirements have been conveyed to you from your interview team, they supersede the following: -## Technical Requirements +## Requirements - [ ] You can select the language you think is the best for this challenge. If you decide to use a functional programming like elixir just let us know first. -- [ ] You are free to add any library that improve the development experience. Like, linters, formatters, etc.Try to emulate the environment that you would like to have when you are working. +- [ ] You are free to add any library for improving the development experience, like, linters, formatters, etc. Try to emulate the environment that you would like to have when you are working. - [ ] You should design your APi for evolvability. Given that in real life no API stays static for long. - [ ] You can use any API paradigm. Rest, RPC or GraphQL depending on what you think is best for the challenge. - [ ] The app should have the tests that you decide are necessary for maintainability -- [ ] You should handle all success and errors the endpoints could have. When there is an error the backend should notify the client about it in such a way that allows the client side to decide what to do. (Ex. If the client tries to create an article without a title we expect the API to notify the user that the title is a required attribute in order to create an article) -- [ ] There should be a way for your user to discover how to use the API. It can be a document, postman, swagger or a plain html website. Is up to you but it should allow the user to discover all your endpoints, and their possible responses (success and error) +- [ ] You should handle all success and errors cases the endpoints could have. When there is an error the backend should notify the client about it in such a way that allows the client side to decide what to do. (Ex. If the client tries to create an article without a title we expect the API to notify the user that the title is a required attribute in order to create an article) +- [ ] There should be a way for client users to discover how to use the API. It can be a document, a postman, a swagger document or a plain html website. Is up to you but it should allow the user to discover all your endpoints, and their possible responses both success and errors. ## API Specification We want to create an API that allow us to handle articles that could be shown in many clients like mobile apps, websites and text to speech apps, etc. - An article commonly follows this process. - --> draft -> published + For this challenge assume that the writers are already store in the application database. You don't need to create a registration endpoint + ## Actors @@ -28,17 +27,40 @@ We want to create an API that allow us to handle articles that could be shown in Is any person that wants to read the articles published in the API. It doesn't have to authenticate herself to do it. ### Writer + Is a person that have the permission to create new articles in our API. It has to authenticate herself in order to create, edit and publish articles. +## Entities + +This is a list of entities that need to be on the API. + +### Article + +An article can be on two possible states. The first one is **drafted** that means that only the writer can see it. The second one is "published" that means that everyone can see it. + +Article attributes: + +- title +- body +- published date +- created_at +- state + +### Writer + +Writer attributes: + +- first name +- last name + ## User Stories -- [ ] As a writer I should be able to create an article in draft state -- [ ] As a writer I should be able to publish a draft article -- [ ] As a writer I should be able to move an article from publish state to draft state +- [ ] As a writer I should be able to create an article +- [ ] As a writer I should be able to change an article status from drafted to published or viceversa. - [ ] As a writer I should be able to edit any of my articles -- [ ] As a writer I should be able to list all my articles (published and in draft state) -- [ ] As a writer I should be able to see only my draft articles or only my published articles -- [ ] As a writer I should be able to see one of my draft articles +- [ ] As a writer I should be able to list all my articles (published and drafted state) +- [ ] As a writer I should be able to see a list of only my drafted articles or only my published articles +- [ ] As a writer I should be able to see one article - [ ] As a writer I should be able to do everything a visitor can do in the API - [ ] As a visitor I should be able to list all the published articles order by published date in descending order - [ ] As a visitor I should be able to see a published article @@ -53,39 +75,10 @@ Take 1 or 2, we don't expect for you to do everyone of them. - [ ] Write down every tool or methodology that you know for improving backend developer happiness explaining why you think they are necessary. - [ ] Create a deployment pipeline that runs linters, tests, ect every time any branch is push it to the repository. In addition, when a PR is merged to master(main) branch then the app should be deployed. - [ ] Write down the name of the strategies or, a little paragraph explaining how you would prevent all or some of these security vulnerabilities. - - Distributed Denial-of Service attacks + - Distributed Denial-of Service attacks - Cross Site Request Forgery attacks - Man in the middle attacks - SQL Injection attacks - Lack of Resources & Rate Limiting - or other possible security considerations. write strategies we could use to prevent it. - - -### Writer -- [ ] A writer should be able to create an article in a draft state -- [ ] A writer should be able to publish a draft -- [ ] A writer should be able to list all her draft articles -- [ ] A writer should be able to see her draft article -- [ ] A writer should be able to delete any of her draft articles -### Visitor -- [ ] A visitor should be able to see a list of all published articles ordered in descending order by published date -- [ ] A visitor should be able to list a published article -### Admin -- [ ] An admin should be able to publish an article -- [ ] An admin should be able to list all draft articles -- [ ] An admin should be able to see any article in the platform -- [ ] An admin should be able to delete an article - - -## Bonus - -- [ ] Build a frontend for the service in any frontend framework that allows users to submit a URL to shorten it in a form, and see the result. -- [ ] Extend your frontend to allow a text file full of URLs to be submitted to the bulk API. Results can be rendered directly on the page or downloaded as a text file. -- [ ] Add a view to list all the URLs and their short versions. - -## Things to grade - -- Extensibility of the API -- How easy is for your clients to implement the API -- Error handling -- Api Design + or other possible security considerations. write strategies we could use to prevent it. + From 3dab61bd15240a968d7bcc4cb23ebb14fbcba034 Mon Sep 17 00:00:00 2001 From: Hidalgo Date: Tue, 3 Nov 2020 16:43:12 -0600 Subject: [PATCH 3/5] move requirements below api specification section --- back_end/README.md | 29 ++++++++++++++--------------- 1 file changed, 14 insertions(+), 15 deletions(-) diff --git a/back_end/README.md b/back_end/README.md index de8a9b3..45ba6ea 100644 --- a/back_end/README.md +++ b/back_end/README.md @@ -1,26 +1,15 @@ # Backend Project -The following project is to build a simple service leveraging API best practices. +The following project is to build a simple service leveraging API best practices. This should take you 4 hours to complete, but you are free to spend more time on it. If any special requirements have been conveyed to you from your interview team, they supersede the following: -## Requirements - -- [ ] You can select the language you think is the best for this challenge. If you decide to use a functional programming like elixir just let us know first. -- [ ] You are free to add any library for improving the development experience, like, linters, formatters, etc. Try to emulate the environment that you would like to have when you are working. -- [ ] You should design your APi for evolvability. Given that in real life no API stays static for long. -- [ ] You can use any API paradigm. Rest, RPC or GraphQL depending on what you think is best for the challenge. -- [ ] The app should have the tests that you decide are necessary for maintainability -- [ ] You should handle all success and errors cases the endpoints could have. When there is an error the backend should notify the client about it in such a way that allows the client side to decide what to do. (Ex. If the client tries to create an article without a title we expect the API to notify the user that the title is a required attribute in order to create an article) -- [ ] There should be a way for client users to discover how to use the API. It can be a document, a postman, a swagger document or a plain html website. Is up to you but it should allow the user to discover all your endpoints, and their possible responses both success and errors. - ## API Specification -We want to create an API that allow us to handle articles that could be shown in many clients like mobile apps, websites and text to speech apps, etc. +We want to create an API that allow us to handle articles that could be shown in many clients like mobile apps, websites, text to speech apps, etc. - For this challenge assume that the writers are already store in the application database. You don't need to create a registration endpoint + For this challenge assume that the writers are already store in the application database. You don't need to create a registration endpoint. - ## Actors ### Visitor @@ -65,12 +54,22 @@ Writer attributes: - [ ] As a visitor I should be able to list all the published articles order by published date in descending order - [ ] As a visitor I should be able to see a published article +## Requirements + +- [ ] You can select the language you think is the best for this challenge. If you decide to use a functional programming like elixir just let us know first. +- [ ] You are free to add any library for improving the development experience, like, linters, formatters, etc. Try to emulate the environment that you would like to have when you are working. +- [ ] You should design your APi for evolvability. Given that in real life no API stays static for long. +- [ ] You can use any API paradigm. Rest, RPC or GraphQL depending on what you think is best for the challenge. +- [ ] The app should have the tests that you decide are necessary for maintainability +- [ ] You should handle all success and errors cases the endpoints could have. When there is an error the backend should notify the client about it in such a way that allows the client side to decide what to do. (Ex. If the client tries to create an article without a title we expect the API to notify the user that the title is a required attribute in order to create an article) +- [ ] There should be a way for client users to discover how to use the API. It can be a document, a postman, a swagger document or a plain html website. Is up to you but it should allow the user to discover all your endpoints, and their possible responses both success and errors. + ## Bonus Points Take 1 or 2, we don't expect for you to do everyone of them. - [ ] Update the list of user stories, and the API documentation if we add a new actor called Admin that is the only one with the permission to publish articles but only when an article is "ready to review". Think about how that new actor will change your current implementation and what changes you will need to do. - - [ ] Deploy the API in a Platform as a Service (Heroku, Blue Ocean, AWS, GCloud, etc) +- [ ] Deploy the API in a Platform as a Service (Heroku, Blue Ocean, AWS, GCloud, etc) - [ ] Dockerize the development environment so the database, programming language version, etc lives in a container. The idea is that when a new developer starts on the project she will not have to configure the development environment by hand. - [ ] Write down every tool or methodology that you know for improving backend developer happiness explaining why you think they are necessary. - [ ] Create a deployment pipeline that runs linters, tests, ect every time any branch is push it to the repository. In addition, when a PR is merged to master(main) branch then the app should be deployed. From e6b377cf8a391f30d58f40b14923a2d360dc3093 Mon Sep 17 00:00:00 2001 From: Hidalgo Date: Thu, 5 Nov 2020 18:59:52 -0600 Subject: [PATCH 4/5] make authorization part of the challenge a bonus points --- back_end/README.md | 31 +++++++++++++++++-------------- 1 file changed, 17 insertions(+), 14 deletions(-) diff --git a/back_end/README.md b/back_end/README.md index 45ba6ea..62f3d00 100644 --- a/back_end/README.md +++ b/back_end/README.md @@ -32,27 +32,26 @@ Article attributes: - title - body - published date -- created_at -- state +- state (drafted or published) ### Writer Writer attributes: -- first name -- last name +- email +- password ## User Stories -- [ ] As a writer I should be able to create an article -- [ ] As a writer I should be able to change an article status from drafted to published or viceversa. -- [ ] As a writer I should be able to edit any of my articles -- [ ] As a writer I should be able to list all my articles (published and drafted state) -- [ ] As a writer I should be able to see a list of only my drafted articles or only my published articles -- [ ] As a writer I should be able to see one article -- [ ] As a writer I should be able to do everything a visitor can do in the API -- [ ] As a visitor I should be able to list all the published articles order by published date in descending order -- [ ] As a visitor I should be able to see a published article +1. [ ] As a writer I should be able to create an article +2. [ ] As a writer I should be able to change an article status from drafted to published or viceversa. +3. [ ] As a writer I should be able to edit any article +4. [ ] As a writer I should be able to list all articles (published and drafted state) +5. [ ] As a writer I should be able to see a list of all drafted articles or all published articles +6. [ ] As a writer I should be able to see one article +7. [ ] As a writer I should be able to do everything a visitor can do in the API +8. [ ] As a visitor I should be able to list all the published articles order by published date in descending order +9. [ ] As a visitor I should be able to see a published article ## Requirements @@ -68,7 +67,11 @@ Writer attributes: Take 1 or 2, we don't expect for you to do everyone of them. -- [ ] Update the list of user stories, and the API documentation if we add a new actor called Admin that is the only one with the permission to publish articles but only when an article is "ready to review". Think about how that new actor will change your current implementation and what changes you will need to do. +- [ ] Make the changes on your APP, so it complies with these new user stories. Note that these stories have conflicts with the previous stories 2,3,4 and 5. + 1. [ ] As a writer I should be able to edit only my articles + 2. [ ] As a writer I should be able to only change my articles status from drafted to published or viceversa. + 2. [ ] As a writer I should be able to list see only my articles (published and drafted state) + 3. [ ] As a writer I should be able to see a list of my drafted articles, or my published articles. - [ ] Deploy the API in a Platform as a Service (Heroku, Blue Ocean, AWS, GCloud, etc) - [ ] Dockerize the development environment so the database, programming language version, etc lives in a container. The idea is that when a new developer starts on the project she will not have to configure the development environment by hand. - [ ] Write down every tool or methodology that you know for improving backend developer happiness explaining why you think they are necessary. From 45ceddfdb0d235f93814582a4b7e2ee1a4c1194d Mon Sep 17 00:00:00 2001 From: Hidalgo Date: Fri, 6 Nov 2020 18:44:42 -0600 Subject: [PATCH 5/5] add two more bonuses --- back_end/README.md | 52 +++++++++++++++++++++++++--------------------- 1 file changed, 28 insertions(+), 24 deletions(-) diff --git a/back_end/README.md b/back_end/README.md index 62f3d00..612c3f3 100644 --- a/back_end/README.md +++ b/back_end/README.md @@ -1,6 +1,6 @@ # Backend Project -The following project is to build a simple service leveraging API best practices. This should take you 4 hours to complete, but you are free to spend more time on it. +The following project is to build a simple service leveraging API best practices. This should take you about 5 hours to complete, but you are free to spend more time on it. If any special requirements have been conveyed to you from your interview team, they supersede the following: @@ -43,44 +43,48 @@ Writer attributes: ## User Stories -1. [ ] As a writer I should be able to create an article -2. [ ] As a writer I should be able to change an article status from drafted to published or viceversa. -3. [ ] As a writer I should be able to edit any article -4. [ ] As a writer I should be able to list all articles (published and drafted state) -5. [ ] As a writer I should be able to see a list of all drafted articles or all published articles -6. [ ] As a writer I should be able to see one article -7. [ ] As a writer I should be able to do everything a visitor can do in the API -8. [ ] As a visitor I should be able to list all the published articles order by published date in descending order -9. [ ] As a visitor I should be able to see a published article +1. As a writer I should be able to create an article +2. As a writer I should be able to change an article status from drafted to published or viceversa. +3. As a writer I should be able to edit any article +4. As a writer I should be able to list all articles (published and drafted state) +5. As a writer I should be able to see a list of all drafted articles or all published articles +6. As a writer I should be able to see one article +7. As a writer I should be able to do everything a visitor can do in the API +8. As a visitor I should be able to list all the published articles order by published date in descending order +9. As a visitor I should be able to see a published article ## Requirements - [ ] You can select the language you think is the best for this challenge. If you decide to use a functional programming like elixir just let us know first. +- [ ] You are free to decide the high level architecture of the app. - [ ] You are free to add any library for improving the development experience, like, linters, formatters, etc. Try to emulate the environment that you would like to have when you are working. -- [ ] You should design your APi for evolvability. Given that in real life no API stays static for long. +- [ ] You should design your API for evolvability. Given that in real life no API stays static for long. +- [ ] The API clients are going to be mobile devices. - [ ] You can use any API paradigm. Rest, RPC or GraphQL depending on what you think is best for the challenge. - [ ] The app should have the tests that you decide are necessary for maintainability -- [ ] You should handle all success and errors cases the endpoints could have. When there is an error the backend should notify the client about it in such a way that allows the client side to decide what to do. (Ex. If the client tries to create an article without a title we expect the API to notify the user that the title is a required attribute in order to create an article) -- [ ] There should be a way for client users to discover how to use the API. It can be a document, a postman, a swagger document or a plain html website. Is up to you but it should allow the user to discover all your endpoints, and their possible responses both success and errors. +- [ ] You should handle all success and errors cases the endpoints could have. When there is an error the backend should notify the client about so allows the client side to decide what to do. (Ex. If the client tries to create an article without a title we expect the API to notify the user that the title is a required attribute in order to create an article). +- [ ] There should be a way for client users to discover how to use the API. It can be a document,a postman project, a swagger document or a plain html website. Is up to you, but it should allow the user to discover all your endpoints, and their possible responses both success and errors. +- [ ] Even if you don't implement it you should think of a plan about how you will deploy the application. You don't have to write anything, you can tell us during the interview. ## Bonus Points Take 1 or 2, we don't expect for you to do everyone of them. -- [ ] Make the changes on your APP, so it complies with these new user stories. Note that these stories have conflicts with the previous stories 2,3,4 and 5. - 1. [ ] As a writer I should be able to edit only my articles - 2. [ ] As a writer I should be able to only change my articles status from drafted to published or viceversa. - 2. [ ] As a writer I should be able to list see only my articles (published and drafted state) - 3. [ ] As a writer I should be able to see a list of my drafted articles, or my published articles. -- [ ] Deploy the API in a Platform as a Service (Heroku, Blue Ocean, AWS, GCloud, etc) -- [ ] Dockerize the development environment so the database, programming language version, etc lives in a container. The idea is that when a new developer starts on the project she will not have to configure the development environment by hand. -- [ ] Write down every tool or methodology that you know for improving backend developer happiness explaining why you think they are necessary. -- [ ] Create a deployment pipeline that runs linters, tests, ect every time any branch is push it to the repository. In addition, when a PR is merged to master(main) branch then the app should be deployed. -- [ ] Write down the name of the strategies or, a little paragraph explaining how you would prevent all or some of these security vulnerabilities. +1. Make changes on your App, so it complies with these new user stories. Note that these stories have conflicts with the previous stories 2,3,4 and 5. + 1. As a writer I should be able to edit only my articles + 2. As a writer I should be able to only change my articles status from drafted to published or viceversa. + 2. As a writer I should be able to list see only my articles (published and drafted state) + 3. As a writer I should be able to see a list of my drafted articles, or my published articles. +2. Dockerize the development environment so the database, programming language version, etc lives in a container. The idea is that when a new developer starts on the project she will not have to configure the development environment by hand. +3. Write down every tool or methodology that you know for improving backend developer happiness explaining why you think they are necessary and how a team would use them on their workflow. +4. Create a deployment pipeline that runs linters, tests, ect every time any branch is push it to the repository. In addition, when a PR is merged to master(main) branch then the app should be deployed on a Platform as a Service like Heroku, AWS or GCloud. +5. Write down the name of the strategies or, a little paragraph explaining how you would prevent all or some of these security vulnerabilities. - Distributed Denial-of Service attacks - Cross Site Request Forgery attacks - Man in the middle attacks - SQL Injection attacks - Lack of Resources & Rate Limiting or other possible security considerations. write strategies we could use to prevent it. - +6. Write down what you would add for logging and monitoring of the system. What kind of metrics and logs the application could have and what mechanism for notification you could use to let the team now when something happens? +7. Write down how to handle authentication on multiple types of devices. For example, imagine that this API will be consumed in a mobile application, a web browser, and on a server. How you would handle authentication on each scenario and why? +