I have a scenario where basically:
- Authorized (JWT) user access my API
- If user exists, info get synched with DB, if not, gets created
- ETC ETC
My question is, how would I proceed creating this scenario? There's a lot (ok, 4) parameters that should be in the request, but I don't want to polute the scenario with information that can confuse a normal user reading the scenario.
This is what I have:
Scenario: Non Existent user access the API
Given an authorized user access the API
And user does not exist on API database
When user access the API
Then user details are added to API database
And user does exist on API database
A user accessing the api will have: email, auth0_id, nickname and name. Just not sure if I should code those info on the Scenario or somehow do it on the Context file.
Edit:
Can I have some "parameters" to be set IN the Context file, instead of in the .feature file? i.e. On the feature file I say "Non existent user access the application" and inside the Context file, in the function associated with this step, I make sure I create a user that does not exist on the database and so on? Would this be a good way of keeping thinks separated from the .feature scenarios?
Thanks
I would write it like this:
Scenario: API - new user access the API
Given I have a new user
When I access the API with the new user
Then the user is added to the API database
First step would generate the user details and save them in a variable, second would make the call to the api (using the saved variable and generate the JWT) and the last one will check the details in the api.
You can declare new as parameter like:
#Then /^I access the API with the (new|other_user) user$/
Anyway, you should declare it as simple as possible in a manner that has sense to you can that you can easily reuse.
Related
I only wish to employ Auth0 as my application's API provider but otherwise
would prefer to maintain any and all data about my users within my application's own database, thus, as one might well surmise, my application's database contains a users table along with several related tables. So, once a user signs up for my app, I'd need to create records for that user within the database. Then, once the user logs in via Auth0, I'd like to retrieve that user's data via information contained within the access token. (The field that presents itself as most useful for this purpose is "azp," or "authorized party.")
I'm thinking that, once the user signs up, as part of the effort to create the relevant records within the database, I'd save the "authorized party" value to a field on the users table. (Which field I cannot say, but, for now, this seems as sound a plan as any.) Then, when the user logs in via the Auth0 hosted API, I would retrieve their record from the database via the "authorized party" value.
Does this sound like a reasonable/sound plan? This is my first time building a full-on application from scratch, and, well, this particular detail has me scratching my head.
This is the my web-app "User Settings" page.
I have simplified it to a minimum to better highlight the problem.
To authenticate users I use Auth0, I wanted to use the sub claim user_id to identify the users inside my MySQL database for update and retrieve user's info. Unfortunately the user_id is different for each provider, for example, if the same user with the same e-mail logs-in via Auth0 he gets a user_id if he does it via google he gets another one.
I thought about using email to link logged user to his info.
The problem is in my API. Before the change it was "localhost: 8080 / api / users /: id"
each time it created a new id and in any case it was impossible to recover the data of the single user. Now that I have replaced "id" with "email" my API has also changed in "localhost: 8080 / api / users /: johnsmith#xxx.com".
Before:
After:
In a few words, the request url on the client side has also changed.
I would like to make sure that the GET and PUT requests are made based on the e-mail of the logged user without going to modify the whole back-end.
Sounds like something is wrong with how you authenticate users. If you have multiple ways to authenticate a user, those methods need to be in a one to many relation with the user. For example each user has a list of auth-methods, and whenever an authentication is made you check your table of authentication methods and find the one user it maps to.
Im not sure if you are doing this yourself or if the framework you are using is handling that, but it sounds like you need to change the model to allow many Auth methods for a single account.
Also you could use email, but that is also an "old" way of uniquely identifying users almost every single person has multiple active email accounts nowadays, so you should also have a one-to-many relation for users to emails. What if the user has different email accounts for their Facebook and Google accounts?
See account linking here: https://auth0.com/docs/users/user-account-linking
It is dangerous to trust that the external providers are truthful about what email belongs to who. What if I open a new account using someone else's email on one of the providers? Then I can log into that users account in your application, which is a pretty big security risk.
This question is regarding authorization, not authentication which i will be managing with passportjs. How do i restrict access for data that's bound to specific users without spreading user_id's all over every table in the database?
Should i create a new database user for each new user of my app and restrict access that way? Or is the "user id in every table" approach actually a good way to go?
I'm working on a project right now where someone else wrote the authorization logic and it works using a kind of authorization path in the code so it can find which user a resource belongs to using some breadcrumb logic.
But I'm really at a loss here and I'm having a hard time finding any information regarding this since almost all articles that I find are about authentication rather than authorization. And I do not mean access to a resource, but rather the filtration of data returned from a resource that the user has access to.
If you want to restrict access of users to certain objects, you either have to store that information with the user or with the object.
The latter is the preferred way because it makes permissions disappear with the object. That's the way PostgreSQL does it – it stores an access control list (ACL) with every object.
So you can either use PostgreSQL to implement privileges (then every application user or at least every group with equal privileges has to have a database user, and you can use permissions on tables and columns and row level security), or you implement it in your application and have some sort of ACL with every row in the database.
I am working on an iphone app which uses instagram API..and I would like to know the following things..Is it possible to get data from instagram without user logging?If so, what type of data would be retrieved from it?Is it possible to access data of a specified user?Or is it only possible using social networking sites like facebook,tumblr etc?
thanks
Yes, with a valid client id, you can fetch user information for a specific user id. Information available includes name, bio, website, and profile picture. You can also return multiple users' data using the search endpoint.
Take a look at the User Endpoints documented here: http://instagr.am/developer/endpoints/users/
I also suggest reading Do you need to authenticate? section here: http://instagr.am/developer/authentication/
NOTE: by providing a client id instead of a valid user token, you are counting against your own application's 5000 calls per-hour limit. If you plan on having a large user page, you would need to authenticate each user to avoid this limit.
In a situation, where the user is authenticated on another application (like oAuth or a custom security implementation), how can we simulate login?
What we intend to achieve is:
- use the user identifier key to check if the user exists
- if the user exists, set-up the session for the user
- basically, setup the attribute holder
- assign the user object, so that it is available thru getUser() method
So we are looking at signing-in programatically!
Any light on how do it in the simplest way?
if using sfDoctrineGuardPlugin, i'd do something like:
Redirect user to 3rd part oAuth provider
On success, user returns to you, either create them a new sfGuardUser object, or retrieve the appropriate one (you may need to adapt the schema to have somewhere to store extra oAuth data).
Call myUser()->signIn($user), where $user in the previously retrieved sfGuardUser object - eg: I use this in register actions to log people in after registration: $this->getUser()->signin($user);