I have several pages in asp.net each with lots of controls. I Also have some roles in my application that each has some setting options. Now I want to prepare my page based on these settings. Maybe it’s not too clear, so please take a look at my example.
Example: There are some buttons, some textboxes, some datetime picker, and a chart in a page, now what I want is when a user sees this page, the controls appear and disappear based on the users role. An important thing is that I don’t want to have only visible and invisible controls, in some scenarios I need to show controls with some customizations. For example change chart data source, limit selecting date time and so on.
The first solution that I can think of, is saving the settings in database and after visiting the page by user, the settings fetch from database and based on those, I can customize the controls with conditional phrases (if and else). But I suppose it is not a good approach and my page will get very messy.
Please help me with any better solutions and if you know good references about it, please let me know.
Please see this link...use of ControlAdapters may help you...
Role-based enabling/disabling of controls in asp.net
You must use Thread.CurrentPrincipal.
A. When user login to your application, you attach his identity to thread, for example
string[] rolesArray = .....; //Get roles from dataBase by identity.
Thread.CurrentPrincipal = new YourCustomPrincipal(new YourCustomIdentity("YouName", "..."), rolesArray);
B. And when you navige about your application you test Thread.CurrentPrincipal
IPrincipal threadPrincipal = Thread.CurrentPrincipal;
if(threadPrincipal.Roles.Contains("roleTest"))
{
//Adjust your control
}
Related
Thanks for any thoughts. This question refers to an ASP.NET 4.0 web application.
A DetailsView then uses an ObjectDataSource (although any solution should apply to any of the ASP.NET DataSource controls) for CRUD operations.
A user has permission to view details for all records, but can only create or modify a single record related to their own department.
obviously I can easily modify the listview to show/remove the appropriate buttons
if (!_canModifySelectedWard)
{
dptDetailView.AutoGenerateEditButton = false;
dptDetailView.AutoGenerateInsertButton = false;
dptDetailView.AutoGenerateDeleteButton = false;
}
but this is only removing the buttons. Is there a neat way to disable the ability to edit/insert/delete functionality? I think a malicious request is highly unlikely once the user has access to this page, but it seems better practice to remove functionality, not just UI elements.
I can set the associated objectdatasource's InsertMethod etc. to null, but this almost seems like a hack.
Your object data source is tied to an class which is responsible for providing the data requested by the object data source. This is where additional checks should be performed to ensure unauthorized access to data doesn't happen.
Hiding the buttons is a good idea from a user experience perspective, but you should always make sure your business rules are being enforced.
Sorry I cannot provide any more detailed help. Perhaps if you could describe what you have going on in more detail, or post some code that would help.
Cheers.
I have the need to populate a combobox in InfoPath with all the users from our Active Directory system. I'd also like this combo box to have auto-complete Can someone please point me in the right direction to accomplish this? Everything I find on the web seems to only load the currently logged-in user.
Thanks in advance!
If you have sharepoint server on your domain you can take advantage of contact selector control described here.
Otherwise you will be to forced to create some code in C#. Basiclly you have two options
Create custom control in C# and use it in infopath. Tutorial
Create standard infopath combobox and bind it to dynamically created collection in custom C# code.
This will be needed for both options: Extensive tutroial how to use class from DirectoryServices namespace.
Based on the comment I think you should take a look at this post about adding multiple contact selector controls into one infopath form and also this thread.
You'll have a bit of learning to do here I am afraid. You'll need to write an LDAP query to get this information. LDAP is a bit of a chore to learn. Using .NET, you can get some help from System.DirectoryServices namespace for help. e.g.:
var searcher = new DirectorySearcher("(objectCategory=user)");
var results = searcher.FindAll();
for (int i=0; i<results.Count; i++)
{
Console.WriteLine(results[i].GetDirectoryEntry().Name);
}
You'll probably need to refine the filter to limit searches to a particular OU to avoid returning service accounts and the like. You'll also want to look at pulling back properties for the user's Fullname etc.
Another route that might be MUCH easier is if your domain has Exchange, you could use the Exchange web service to query the global address list?
i have a form where i have the field "Real Cost" i want to customize its appearance and wither it should be validated based on user role.
to be more clear is say the client want to show his field in the form or details page and also make it editable for users in Roles "Senior Sales, Manager" but not other roles, so can anyone please guide me of the best way ?
should i write custom required validation based on user in role, and if so can you please provide the right implementation of it?
some may tell me create custom model for this, but i think it would be hassle plus the Roles will be dynamic so it is not predefined set of roles.
i hope i was clear enough
Security is definitely something that should be happening in the model or the controller but never in the View -- that is well beyond the View's scope of concern. Which is to display the data that the controller gives it.
To expand on #Wyatt you need to make all these decisions at the model level and then populate a 'View Model' with all the answers, which then can be used in the view to improve user experience.
In the ViewModel for this form, have a property IsRealCostEditable, which will be set by your service/model layer by checking the user's role. Now you can easily adjust the UI for that field.
You can create duplicate pages and one page can contain the view model which doesn't changes anything in the page... AND you can have an EDIT button which redirects to the editable page.
Make that page protected with authentication. SO you will asked to authenticate as your role before you can edit it
OTHERWISE.. there is no way your ViewModel can make decisions, its on the Service Layer.
What is the best way to show different form fields for different user in ASP.NET?
Here is an example:
I have a form which has TextBox1, TextBox2, and TextBox3.
User A can only see TextBox1 and TextBox3.
User B can only see TextBox2 and TextBox3.
...
If there are a lot of users or form fields. It will be too tedious to code all the logic.
Is there any elegant way to achieve this without hand-coded logic?
You can use the LoginView Control. This is a small how-to.
I like grouping related controls with panels, however if the differences are small between groups of users, turning controls visibility on or off might be good enough.
Just make sure you test each different scenario, as often this is where testing falls down.
If there are lots of controls, it might be worthwhile looking at creating them dynamically.
If you're using role-based authorization, you could write something similar to ReadWriteAuthorization in CSLA.
This is an extender control which enables/disables/sets read-only or empties controls based on the user being able to read or write the specific property the control is bound to.
This could be enhanced to also show/hide controls. Of course this also means your business objects need to know which properties can (or can't) be viewed by which roles.
Another possible way is to use Profile in ASP and storing controls properties for each user in Profile.
In this way, controls properties can be loaded during page load.
Such as,
labelPostalCode.Text = Profile.PostalCode;
Reference:
http://msdn.microsoft.com/en-us/library/taab950e.aspx
I've been trimming the UI of our website by doing the following in the onload event of that control:
btnDelete.isVisible = user.IsInRole("can delete");
This has become very tedious because there are so many controls to check again and again. As soon as I get it all working, designers request to change the UI and then it starts all over.
Any suggestions?
One simple suggestion would be to group controls into panels based on access rights
Something I have done before has been to create a custom page class (Actually, I do this part on every project) that each ASP.NET Page inherits.
This page class contains an IsAdmin property.
I then subclass the commonly used controls that may or may not be visible between modes into custom controls, and add code to check the Pages IsAdmin property.
All this is maybe an hour of work, but if you build pages using these controls, they manage their mode automatically.
Another fun timesaving tip is if you need to flip the page in and out of readonly mode. I added a property to the main base class, and then added a custom control that renders a textbox in one mode, and a label in the other.
Again, a little bit of time on the components, but then you can create a readonly version of the page in 2 lines of code...Very worth it.
You may be thinking of the situation in the wrong way. Instead of thinking of individual controls, think of it in terms of business roles and what they have the ability to do. This goes along with grouping controls into panels for access rights. For example, maybe only managers have the ability to delete and do other things, and you have a role for managers that you check. This way if there are changes, you can just move users into different roles. Business rules should not change drastically. There will always be tweaking as new positions gain more responsibility, but thinking of it in this way should minimize the number of changes to be made.
A quick and dirty option is using the asp:loginview controls, which can be wired up to user roles.
Not as elegant as the custom page class option suggested by Jonathan, and can be a bit of a performance hit if they are all over the page.