Ive got a asp.net mvc site that works with ASP.net Authentication. I have a UserInformation table which stores extra information on each user aswell. On pretty much every page i am calling to the database to pull the UserInformation record for the current user at least once.
Im thinking all these repeated data calls for the same information has to be overkill. Is there anyway i can cut these down? Caching? Storing the userinformation record for future use etc etc?
Im sure im not the first person to come across this issue, so i didnt want to reinvent the wheel.
Thanks in advance
You could use a custom IIdentity and IPrincipal. Here's a nice article describing how to achieve this (the interesting part is happening in the btnAuthenticate_Click method which in an ASP.NE MVC application would be the authenticate controller action, here is emitted the authentication ticket with custom data). In this example the idea is that the authentication ticket is manually created and the userData property is used to store additional information. This might not be appropriate for your case if you have lots of data because this is stored in a cookie. But instead of using the userData you could store it somewhere else like Session or Cache. You could also write a custom [Authorize] attribute to deal with the custom principal (the part that corresponds to the Application_AuthenticateRequest method in the article should go in this custom authorization filter in order to reconstruct the user back).
Related
As the title says, I'm developing a Custom User Storage Provider (here forth SPI) with Keycloak 15.0.2.
I’m having trouble sorting an issue where the very first access token that is issued, does not match the expected format (is missing some fields) but also seems to be issued for a different user, if I am to judge only based on the sub field of the AccessToken generated.
To ease reproduction of the issue, you can find my repository on Github here with a complete sample FE and BE along with the keycloak configuration. I also included samples of the result tokens, jwt.io links and logs on LOGS.md file on the repo.
I think I understand why this mismatch is happening, though.
Due to the fact that I start with an empty collection of users on keycloak, I need to create the users on their first login. All I have to start with is their email address which is input on the login screen.
With this information, I setup a “temporary” Federated User until I get the user data from the “real” IDP on the isValid method (where the user actually logs-in into the third party IDP) and then get his details, which are then used to fill a more complete FederatedUser profile and store it on the userLocalStorage.
It's basically this logic (it's all also explained in comments in the repo's code):
Create an adapter/model based solely on the email from the login form to be used temporarily.
Proceed with normal operation.
Then on the isValid() method:
login the user through the REST call to the backend and get the JSESSION token
on a separate call, call the Current-User REST endpoint to get user details and map them to a Dto object
create a new adapter, based on the Dto object (which already contains all the user details like name, phoneNumber, etc) and from that, add to storage as a ksession.userLocalStorage().addUser() user and enrich with custom attributes (to later be mapped into the AccessToken)
when (and if) added, clean cache with ksession.userCache().clear()
Proceed with normal operation
However, I think that the ID/model of that first temporary user is the one that is actually being used during the issuance of the first AccessToken that is generated and is being cached somehow on some other class which then generates the AccessToken with missing information/not the correct user model.
When I reload the page (forcing it to go through the login flow again), I then get the correct AccessToken with all the fields I expected the first one to have. I also noticed that the sub of the tokens are different, and this is what leads me to this conclusion.
Does this flow/conclusion seem correct to you?
And more importantly, how can I fix this?
I have no way of getting all the user data at first or a way to import it (ideally, I didn’t even wanted to Federate, just some ReadOnly data would have been enough if I could modify the AbstractUserAdapter attributes).
Can I somehow access the CredentialInput outside the isValid method?
That’s the only way I’d have to grab all the user data since the beginning.
I’d really appreciate any help you could spare. The reproduction code is just a clone/docker up away and will replicate the issue perfectly.
Please help me figure out how to make sure the token get properly set/issued the first time around
Thanks
Let's assume I have a project similar to the google sample code:
https://github.com/googlesamples/android-architecture-components
I want to add an account system to the app. How can I persist data and make the following scenario work:
go to persistent-data-fragment and load data from backend
log out
log into a different account
go to that same fragment
As a result, I should not be able to see the first user's data and instead load them from backend for the second user. How to use Room for that?
It a generic question, so I can answer with a generic answer :).
1 - on the server side you need to authenticate a user that access to REST services. There are many ways to do this. JWT is a good solution. Start reading this article.
2 - on the client side, probably you need to introduce in your database a user table and link other database's entities to user identity. Using Room you have to declare a user bean and then link them to other room entities.
I hope it helps.
Philosophically, I had questions about some examples on how to tackle the following REST scenarios:
1) A user who is signed in wants to 'favorite' someone's blog posting. The user id is a guid and the blog posting is a guid. Should this be a PUT because user/blog exist, or POST because there is no entry in the 'favorites' table?
2) A security row in the DB consists of 10+ properties, but I'd only want to update one part of the entity (# of failed login attempts for a user). What should the call be? Pass the entire data transfer object in JSON? Or just add a new api route for the specific action to update? I.e. a PUT with just one parameter (the # of login attempts) and pass the id of the user.
3) Similar to #2, a user class (consisting of 25+ properties) but I'd only like the user to update a specific part of the class, not the whole thing. Philosophically do I need to pass the entire user object over? Or is it OK to just update one thing. It seems I could get crazy and make lots of specific calls for specific properties, but the reality is I will probably only update 2-3 specific parts of the user (as well as obviously updating the whole thing in other cases). What's the approach here for updating specific parts of an entity in the DB?
Thanks so much
Use a POST if you don't have an ID/UUID yet.
The resource is the security record. Do a PUT on that ID, and pass a block of the properties to be changed.
Ditto (2). You should get whatever parameters will help you identify that record in the DB. If it's unsavory to send these in the POST request and you're doing AJAX, just stash them in the session.
With REST, everything is about updating discrete resources ("nouns"). It's up to you how you want to assign these, but a simple interface that uses verbs ("PUT", "GET", "DELETE", etc..) sensibly, returns relevant HTTP codes, and is easy for others to implement is the best way to go.
So, just ask yourself, "What nouns do I want to give CRUD to, and am I going to exhaust people who wish to consume my API?"
I'm working on a small marketing project with Zend Framework, the backoffice of the project is currently made of two controller: a campaign controller and a minisite controller.
The user create a campaign with a form, then he have to create a minisite with a second form linked to this campaign, so i need to get the campaign and the user id when saving the data of the minisite.
What is the best practice and why? should i pass those variables in a session object? or should i pass those variables through a route like :
/backoffice/minisite/create/:userid/:campaign/
Edit: users are logged and authenticated when creating campaigns
Assuming users have to be logged in to do this, you could store the user information you need in a Zend_Auth identity
If not, you could store the data in a normal session var with Zend_Session or redirect to with the route. Either option is good, so it's up to you to pick the one which best suits you and your application.
For passinf information between two controller the best way is to use session to store the values globally . :-)
I'm pretty sure users need to have an account to do these things. If yes, there campaigns and minisites will be associated with them in some way. I'd store and retrieve these things from some form of database.
If you're not having authenticated users and you really just need to pass two variables to another action, use url parameters but be aware of the fact that users can mess with them and a lot of unexpected stuff can happen. Storing in the session is harder to manipulate in that way.
So, if no authentication is involved and the site is public, use the session, otherwise use neither but use storage.
I would use the route option, as you suggest. Using sessions is going to end up being very difficult to test, debug, extend in the future etc.
Hi,
I am building a ASP.NET MVC 2 website and need to bound the current user/session to some data. The following is possible solutions but what is best practice?
Create a GUID and set it as hidden field on view, the data will then be saved in a singelton object (like a cache). the security will however not be the best(the user could change the value of the hidden field).
Use Session.SessionId. to maintain the same SessionId between calls I need to store somthing in the session which feels wrong? Im not sure if there is any security problems here?
BestRegards
My Solution : I ended up to create a GUID for the current client and then set this as a hidden field on the form. I did however had some problems to get the hidden field to be rendered correcly, see : ASP.NET MVC 2 HiddenField is empty?
Maintaining state across web requests is always a challenge as the web is inherently stateless.
Whether you use a hidden Guid (or other system-unique identifier) or a session ID in a cookie, both are open to abuse. That said, most systems that implement a 'session state' do so through the use of cookies.
The purpose of the session state 'bag' is to store information between web requests, exactly the objective you mention, so while it may feel 'wrong' it is a very commonly accepted approach. Remember, only the session ID is stored with the client browser, not the actual session data; that's held at the server.