I need a Global variable/class that stores some basic information about the currently logged in user including that user's preferences, security rights, UserID, etc. This information will be needed by any/every part of my application.
In the past I have either used a Public variable/class in a vb.net module for this purpose. I'm trying to get away from my old ways of doing things and was curious what people currently do for this functionality.
I am thinking a singleton or 2 regarding preferences and security but am not sure if that is the best way to go.
EDIT: This is an n-Tier WinForms application.
In my ASP .net web app, I store an object that contains login information for that user in the Session Cache. That is one way.
If you want different "global variables" for each user, then sessions are the way to go (as Russell mentioned). If you want variables that are the same for every single user, then Application variables are what you want.
Related
I am fairly new to coding in the .Net environment. I am having trouble finding "real-world" examples on authentication/authorization using Identity. Most examples I come across are primarily textbook examples that use the ASP .Net registration template.
I am trying to find guidance on where to look (yes, I Googled and I get very unrealistic/unusable use cases or "classroom" examples) or how to do this.
I work for a small school and I am trying to build an application (possibly Blazor - just experimenting with various technologies now) that allows both students and employees to login into a portal and view their relevant data. I have an Employee table and a Student table based on POCO classes. When I add identity to the project it creates Users and Roles tables as well.
I would like to have the "Users" table based on the Student and Employee tables - not have a separate users table. I do not want to have a "registration" option either. I would like the option for an Admin (which would fall under an "Employee") to be able to add users, but not use a registration page.
How would I implement Identity and Roles without using all the extras added? I am using .Net 5.0.
Thank you for your time and pelase forgive the English - it's new to me as well.
I understand what you're trying to do. It IS possible to Create a Custom AuthenticationStateProvider
But unless you have a VERY robust database already, I wouldn't do it. Getting the default system set up and migrating users will take at most an hour. Setting up your own custom authorization system is likely to take you MUCH MUCH longer.
Having different users in different tables is not a good design plan. They all have names, phone numbers, e-mails and so on-- put them on one table.
Hi Derrick and welcome to the community! #Bennyboy1973 is correct, in that both your Students and Employees are all "Users", so they should all be stored in the same table. To add to that response a bit, probably the simplest way for you to manage them is by using Roles, so the Students could be in one role and the Employees could be in another. By having a role attached to each, you can then use the roles as a filter in your queries and you could also restrict the access and actions each type will have based on the role they are in.
Regarding having administrators add the users to the database without public access, this can be done as well. Once you get the default identity system up and running, you can scaffold out the whole system so it can be modified, and probably the easiest way to achieve what you are after is to then modify the default registration (signup) page so that it requires the user to be authenticated to reach it, and then implement a confirmation email to activate each new account.
There are a few things with this approach that you need to be aware of as well.
Since the admin will be setting up all the other user accounts, you should modify the email confirmation chain to require a password reset at some point. The administrators can have access to the user's information as needed but shouldn't have the user's passwords.
Identity Server will store passwords in an encrypted format, and you'll need an initial user in your database. What this means is that you will have to "seed" an initial admin user into the database that you can use to sign in and get started with everything else. You'll have to research how to do this, as it isn't as simple as just accessing the database directly and adding the user and roles because of the encryption. The program you build should be designed to do this for you on either the first run or if you are connecting to a new database, using a username and password that you know. It will then store the user properly that you can use to sign in as Admin, then change the admin password. This makes the whole thing more secure.
This all sounds like a headache, but it's worth it to work through and know how it all fits together. The, as mentioned in other answers, you can migrate existing data into the database.
For each user that connects to our MVC app, I need to store several custom properties (like its role, a list of sites he has access to, etc.). I know how to get the values for those properties (from our SQL database); what I need to know is the best practice to keep this "singleton/static/unique" object accessible across each view, and avoid to poll the DB each time.
Our authentication is Windows authentication.
Could be misinterpreting what you are asking, but ViewBag/ViewData are good tools for cross View/Controller data.
Hard to find a meaningful title. I hope I get clearer now.
I'm building a service which is similar to doodle regarding the authentication model. The user can "create" something (using a form). There will be two different views. One for the creator where he can modify his settings and another one for public access.
I don't want to force users to register / log in. So I came up with a URL structure like doodle has:
/{some-id} -> public access
/{some-id}/admin/{some-token} -> settings page for the owner
The question now is how I can deal with this best. Currently I pass the token to all admin related Methods. But I don't feel comfortable with that.
I also thought about some server side session. I found two meteor packages but they are both not actively maintained anymore.
Another idea was to misuse the built in user management but without the user to recognize it. But I don't think that's feasible.
So now I'm asking you if you have a nice way of dealing with this. I hope I made clear what I want to do.
There are many ways of doing it. One way is to reuse Accounts package.
You user id is {some-id} and the password is {some-token}.
When you create new page. You create new user on server side using Account.createUser.
When you enter url /{some-id}/admin/{some-token}Meteor.loginWithPassword.
I'm looking into crafting an app with DDD+CQRS+EventSourcing, and I have some trouble figuring out how to do user auth.
Users are intrinsically part of my domain, as they are responsible for clients. I'm using ASP.NET MVC 4, and I was looking to just use the SimpleMembership. Since logging in and authorising users is a synchronous operation, how is this tackled in an eventually consistent architecture?
Will I have to roll my own auth system where I keep denormalized auth tables on the read side? How to handle the security of this? Will I end up storing password hashes in both my event store and my view tables?
So many questions, if anyone can shed some light, I would be very thankful :)
tldr; How do you do User Auth in EventSource-applications?
Not every "Domain" or business component has to use DDD or CQRS. In most cases, user information is really cruddy, so you can usually not use DDD for that. Other domains don't really depend on the actual user. There's usually a correlation id (UserId) that gets shared by the various domains.
If using messaging in your system, one option is to register and manage users without CQRS, then send a command (RegisterUser { UserId } ). This would publish an event User Registered. Other domains can listen to this event to kick-off any workflows or ARs that are needed.
For our MVC CQRS app, we originally started off keeping all the user related information in the domain, and, like somebody mentioned, there was a RegisterUserCommand and a UserRegisteredEvent. After storing the user information in the domain, that event got published and picked up on the read side, which also created a user and generated all the password hashes, etc. We then done the authentication on the read side: the controller would make a call out to a 'read model authentication service' to authenticate against.
Later on down the road, we ended up completely refactoring this. It turned out that we needed access to the user related information to build in security for authorising our commands, which we done on the command processing side (our app is a distributed app that sends 'fire and forget' asynchronous commands to a queue, with an autonomous listener on the other side). The security component then needed a reference to our domain to go and get the user profile, which led to cumbersome referencing issues.
We decided to put the user security stuff into a separate database that we considered to be more of a central component, rather than belonging to the domain or read model. We still maintain user profile related information in the domain and read models (e.g. job title, twitter account URL etc.), but all the security related stuff, like password hashes, are stored in this central database. That's then accessible with a service, that's available to both MVC and the command authoriser.
We didn't actually have to change anything in the UI for this refactor, as we just called the service to register the users from the register user command handler. If you're going to do it that way, you need to be careful here to make your user service related operations idempotent. This is so that you can give your commands the opportunity to be retried without side effects, because you're updating 2 sources of information (the ES and the user database).
Finally, you could of course use the membership providers for this central component, but there can be pitfalls with that. We ended up just writing our own - it's pretty simple to do. That article links to this, which provides a good example of how to implement it.
You should consider creating separate entities like: visitor (just visited your site), user (registered), customer (bought something), etc. Try to split your system in this way, even if it causes a little bit of data redundancy. Disk space is not an issue but ability to modify different components of the system independently is usually very critical.
People create denormalized auth tables only for the purpose of scaling and only if your auth read side is a performance bottleneck. If not - usual 3rd normal form is a way to go.
In SimpleMembership scenario all tables created by SimpleMembership can be viewed as snapshot of "user" aggregate. And yes, they will duplicate some data in your event store.
You may have events like: UserCreated, UserUpdated, UserAssignedToRole, etc.
And don't be tricked by the name of that membership provider. It's not so simple and usually has lots of things that you can easily live without (depends on your domain). So, maybe you can use something like this: https://gist.github.com/Kayli/fe73769f19fdff40c3a7
We're currently evaluating SAP Business Objects XI 3 for a front end reporting solution, but I'm not happy that we will need to create a new set of logins that will be managed independently from our existing website. We have an authentication API that our various applications all hook in to, so we effectively get single sign on, and single account management.
Is there a way to write a custom authentication plugin for SAP BOE 3? I've googled for information and have come up empty handed. Links to documents would be handy also.
The solution that we use for this problem is to have a seperate password management page built into the HR space that will change all the user's passwords to the same thing. So there is one input for username and pass that changes the global password for a user and then it runs through and changes all the different SAP ones that are needed.
Not really the answer you are looking for, but it is somewhat of a solution.