I just finished a starter course in WebAPI.
I went thru token validation.
I want to return a list of items that belong to a user.
The Action Method requires Authorization, but I do not want to use
a session to see the id of the user. However I do not want to pass
the userID as a parameter in the Query from my Angular client.
This would allow another authenticated user to send the ID of a different
user to see their items. I don't want this.
It seems like most WebAPI return results are for common items.
Related
I'm trying to make a user logged in at back-end who is already a user of another website of mine. For now I'm able to fetch the user's data from previous website's database using an API and make user registration during the login process. Same time I want this user to be logged in when data is just inserted because now user is existing. I tried to reuse same method $this->processLogin(); but this method takes request function processLogin(Request $request) I can't feel passing email & pass to utilize this same method. I have tried guzzle self request with 3 parms 'email, password, _token' using POST request which didn't work. I don't want to exclude this route as well because it is being used for normal login. How can i make this user logged in right after inserting the required data? Please advise. Thanks in advance.
// if $id is your user that you want to login, then:
auth()->loginUsingId($id);
Before adding, yes it works when I give the entire url like http://localhost:8080/onedrive/oauth2/success/1 in the list of uri in azure uris. I am using code flow to authroize these tokens.
But as per the docs, it should work with me just mentioning the domain name there, like http://localhost:8080. Which it doesn't.
I want to do something like send the user id along with every request for me to keep track of which user I should link this accees token to, and have no idea to do so, if this issue is there. My current application logic is, when my application sends the user details and calls my spring API, I want to handle all these transfer of tokens in the server side, so I want to transfer this userId as my path variable. How do I go about doing this? Has anyone done this, can they explain to me any other different solution?
You can't add custom details to OAuth redirects and it is best practice to always register the full redirect uri.
In terms of tracking the user, after login the token has a user id and you can also get fields such as user name and email - so both the UI and API will know which user each token is for. I can provide further details on mechanics if needed.
The user id in a token is often a generated value, whereas the user id you want to use in API path segments is maybe a user id from your app's back end database - if so you will need to map between token details and database details.
If you provide redirect uri as http://localhost:8080/ then it means you are handling the api response in
/
endpoint and not
/onedrive/oauth2/success/1
To get to know the user to whom you are linking, few ideas which you can use are
1) Use security to obtain the logged in user credentials (Ex: Principal if you're using Spring security in java)
2) After successful authentication, use the user id you have and send one more request to backend and store it database with userid as a key
I'm looking into an "authenticated URL" type middleware for my Laravel application where a token is generated and that token relates to an authenticated user ID and the hash of a single URL. In other words, a way of viewing a session page from an e-mail without being initially signed-in, using a high-entropy token.
When the user visits the URL, for example https://www.example.com/some/url?authtoken=WDu4UQ5SQr4WGlfMYErxRy3hjdFMs02f2NqbQ7PA, the AuthenticatedUrl middleware looks up the authtoken in the database, verifies the hash of the request's URL and the stored URL match, then logs in the appropriate user ID (Auth::guard('user')->login($token->getUser())) so the page's controller can respond as normal.
That being said, I would prefer to only allow this middleware to authenticate the request itself, not the entire session. Is this possible without causing issues with an existing normal Laravel session?
I discovered the Guard::onceUsingId($id) function which does exactly this. It logs in the request without setting any related session values or cookies.
In Laravel it's very useful to access Auth Facade after authentication in order to get user data like:
Auth::user()
What If during session and users interaction I'd like to enrich the object returned by the above call? Maybe assign some attributes to a user after he performed some action on my webapp?
E.g. A user performs a fast registration, and after while completes some other profile data. I'd like them to be available directly in Auth::user() instead of perform subsequent DB queries...
IMPORTANT
I'm integrating Auth0 into Laravel authentication. So the default driver/provider behind Auth is not Eloquent but Auth0.
Auth0 gives back a Json object containing all authenticated data.
Auth0User->userInfo
What I'm trying to achieve is to edit the Auth data after Auth0 Authentication by adding custom data to Session Object.
Basically I want to use another service to manage account related data, and use Auth0 only for managing user/password grant.
You can add a custom attribute to the User model. For example:
public function getTestAttribute()
{
return session()->get('test', 'defaultValue');
}
It is possible to set the session key somewhere else in your application:
session()->put('test', 'otherValue');
I'm new to the whole client-side SPA world. I'm using the above technologies, which seem quite promising. However, one huge snag that I can't get over easily is the lack of built-in security. I had to manually roll out the user authorization, which IMHO should be part of the framework.
Now that I have that sorted, I'm getting major headaches with vertical security: where one user is logged in but can easily access other users' info by changing a few parameters in the browser console. I could pass the userId with every call and then compare it with the one on the server, but I was hoping that there would be an overarching solution that doesn't pollute the breeze data calls with user ids.
For example, let's say there's a call from the data service like this:
function getItems(){
var query = breeze.EntityQuery.from('Items').expand("Person");
return manager.executeQuery(query);
}
this will get all the items, not good. So let's limit by userId:
function getItems(userId){
var query = breeze.EntityQuery.from('Items').where("userId", "==", authentication.userId).expand("Person");
return manager.executeQuery(query);
}
in the second example, we get the userId from the authentication service, which stored the userId when the user was logged in. However, a malicious user can easily go the browser console and change that value.
Of course, I could pass the userId using withParameters(...) and compare it with the current one on the server, but I'd have to do that for every call, which doesn't seem right. Is there a better way to secure calls with the trusted user id?
#Ali - I understand your pain and your concern. You are right to fear any form of so-called security that relies on information passed in the URL. Fortunately there are excellent answers to your concerns and Breeze apps work well with them.
For example, have you studied the ASP.NET Breeze/Knockout Template? It uses Forms Auth for authentication and guards the Web API controller with an [Authorize] attribute. Only logged-in users can access any of the controller methods.
That authentication also sets the IPrincipal which the Web API controller makes available through its User property. You'll see User passed to the constructor of the TodoRepository. In that repository you'll find guard logic to restrict query and saves to just the Todo information belonging to the requesting user.
Look at the network traffic. You won't find any user identifying information in the URL or the request/response bodies. You will see an encrypted authentication cookie in a header.
An obvious flaw in the example is that the client/server traffic takes place in the clear. You must add transport level security (HTTPS) before you go to production. But this is a demo after all.
Why not just do this in the controller?
If the Web Api is secured with [Authorize] then you can get the users ID in the controller and make sure that the data returned is for the currently logged in user.