|
My company has a winform application with hundreds of forms. The application is close to be released and management now want us to add application level security in it. So basically things like a user X in role Y can do certain things but should not be able to do other things. We cannot reply on the fact that all our clients will have windows domain.
My initial thought about its design is to have some kind of mapping in terms of UI elements in different forms and then make these UI elements read-only based on permissions. Just wondering if there are any patterns of implementing it and if anyone can point me to links for it? I have looked at Security Application Block in Micorosoft Enterprise Library and seem like it can be used for authenticating the users but its probably problematic if you are not on Active Directory (correct me if I am worng here)?
|
|
|
|
|
imak wrote: The application is close to be released and management now want us to add application level security in it
What an excellent planning and design system you have. This is so common it hurts (it is now going to bite you guys).
From a couple of decades of practical experience!
. Internalise you security, manage your authorisation in your application by mapping UI elements to roles.
. We use an AEDX field on a function (UI element) that allows a fine grain control
. Base your authentication on Active Directories, once they log on they are authenticated, then look up your internal authorisation tables.
. Create a base form that all your dialog/forms can inherit that will do your user validation.
We have a main menu and 95% of apps (we have about 15) only require security applied to this level (ie this user group can have the Customer function but has no AEDX rights on the form, therefore it is read only)
Adding security to a major app is not a trivial excercise and testing is a stone bitch! Good luck
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
How are the security roles going to be described to you? Usually in situations like this the business user will describe the security in terms of a business process rather than individial pieces of data. Something like "the accounting role can process invoices" rather than "the accounting role can update the following fields...". If your app is designed along similar business process flows, then the security can probably be applied to a few buttons and menu items or at the form level rather than lots of individual data controls. Mapping each and every UI element to a permission scheme can be terrible for performance. Since this is something that you distribute to multiple clients you also need to decide about how the roles will be managed unless you intend to force the same scheme on all of your customers.
|
|
|
|
|
this is the right time to add application level security. Never think about such things when you start writing your app. Always add security related things in a hurry short before release date - and of course don't waste time testing it. 
|
|
|
|
|
Hello imak,
In one of my application I have implemented Application settings same as you want to right now.
I developed Security Level for each type of user type. Admin can add so for each form/task in the application. When the logged user logs in, reading these set settings user can access or cannot access based on the security settings. For example, you have Customer form :
Customer
Add 0, 1, 2
Edit 0, 2
Delete 0
User Type with Roles (0- Admin, 1-Operator, 2-Receptionist] are set as 0, 1, 2... and so are to the tasks of Custoemr form. So you see
Add can be performed by Admin, Operator & Receptionist;
Edit can be performed by Admin & Receptionist;
Delete can be performed only by Admin
The same if you don't want to do task wise and only form wise, you can do that to by just setting for Customer form and not tasks of the form. So all tasks will be set by all those users.
Hope this helps.
NOTE: Vote if this helps.
Thanks & Regards,
|
|
|
|
|
Hi code project members,
as the title says i want to achieve the following mockup (link to my skydrive, sfw):
FixedToolWindow_WithNoCloseButtonMockup[^]
I tried lots of possible solutions, like removing the menuitem through interop, setting Form.ControlBox to false, but either the close button is still visible, or the formborderstyle changes to one with round egdes.
I definitely would like to create one with the nice rectangular fixedtoolwindow style without all the os provided buttons.
If someone could help me out here, because im kind of lost here.
Thanks in advance.
Balkoth.
modified on Tuesday, August 3, 2010 12:44 PM, to fix the new window link
|
|
|
|
|
AFAIK the only ones you can get right away are shown here[^]. If you need something else, you'll have to do all the painting, i.e. client AND non-client parts.
|
|
|
|
|
Thanks for your help, i was hoping that there was something which i haven't yet discovered to do the magic trick.
|
|
|
|
|
Hi members.
This is the preview, for what i was trying to achieve the effect.
Thanks for your attention.
Greets Balkoth
|
|
|
|
|
Hi all,
I have a tabcontrol with a lot of tabs which may be added and removed dynamically. I'm using a multiline tab control due to the amount of tabs involved, and I would like to simple be able to add a tab to either the top or bottom row of tabs programatically. Is that at all possible?
Thanks..
|
|
|
|
|
ruanr wrote: Is that at all possible?
Yup. Did you run into a non-working insert method? If yes, then there's a workaround[^].
IntPtr h = tabControl.Handle;
tabControl.TabPages.Insert(0, "test");
Alternatively, you could move pages around as shown below 
var tabControl = new TabControl();
tabControl.Parent = this;
tabControl.Dock = DockStyle.Fill;
tabControl.Multiline = true;
Controls.Add(tabControl);
tabControl.TabPages.Add("bla");
tabControl.TabPages.Add("bla2");
tabControl.TabPages.Add("bla3");
var temp = tabControl.TabPages[1];
tabControl.TabPages[1] = tabControl.TabPages[0];
tabControl.TabPages[0] = temp;
I are Troll 
|
|
|
|
|
I work alone, and I have developed a huge desktop app, probably a quarter million lines of code, that has evolved for well over 10 years.
I keep thinking it would be nice to convert it to a browser UI, but have watched many technologies go by, like asp, ajax, and now there's webmatrix, and sometimes I wonder whether I should take the leap, or whether it may cost me another 10 years to rewrite it for the web.
It uses .NET remoting, and is multithreaded, so wcf and parallel programming come to mind as well.
Fear promotes a lack of action, but knowledge defeats fear, so I thought I'd submit this general question to the "big team" out there in the code project universe.
____________________________________________________________________________________
The Vulcan Science Directorate has determined that time travel is impossible.
|
|
|
|
|
BobishKindaGuy wrote: probably a quarter million lines of code, that has evolved for well over 10 year
Converting this to a browser based application is not going to be easy.
It could take ages.....
There are a few plugins [^] that display winforms within browsers and you could consider them.
|
|
|
|
|
Thanks Abhinav.
The plugins reference you cited has a posted date of 2003, so I only spent a moment looking at it, since so many current ideas are very different from what was available at that time.
____________________________________________________________________________________
The Vulcan Science Directorate has determined that time travel is impossible.
modified on Wednesday, July 21, 2010 1:43 PM
|
|
|
|
|
I'm a winforms person by preference and have avoided working with the web, thankfully. However we have just made the decision to move to web delivered UI for all new development. To reverse a 10yo, still evolving app, thats going to be tough for a 1 man show.
A lot would depend on your customers, do you work in a company or do you sell the app as a commercial product? Who is going to foot the bill?
Mind you a total rebuild improves any application. I know any app I built 10 years ago would benifit from it.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Thanks for your thoughts.
I guess a core of basic necessary functions would have to go together on a web UI, and leave less-used functionality as a desktop app. They could use RDC to go in and change some of that. (It's a commercial product.)
____________________________________________________________________________________
The Vulcan Science Directorate has determined that time travel is impossible.
|
|
|
|
|
It was the same with me. I avoided web development for a good long time. I'm only just now really getting into it with a new application I'm developing. It's cool - but it ain't the same as WinForms development - not by a long shot. You had better be ready to edit HTML even with .Net 3.5 or 4.0 to get your forms working. It ain't WYSIWYG - and you have to think completely different. Instead of event-driven, you're talking page lifecycle. Smokes the brain for awhile until you get it.
-Max
|
|
|
|
|
Thanks, Max,
Yeah, I can see that some of the friends suggesting an approach such as is provided with visualwebgui would take some of the pain out of the events versus page lifecycle paradigm. Either way, it's a total change of thinking, which all comes from the issue of sending bytes along a wire asynchrounously instead of counting on resources (code) being instantly available to "answer" some event.
Actually, I think the whole asynch paradigm is what we will all need to do within the next few years. It might be good practice to use delegates for everything within some sub-project just to get used to it. In fact, (philosophising here) I believe asynch thinking is probably more real-world than what we do now, which is like tugging a string and expecting the other end to move. It's like you have a message, so you put it in a bottle, throw it in the ocean, and then you need 100 people to watch the beach for "if and when" an answer comes back in a bottle. The real world works like that - when you order some product by phone or on a website, it's only when the product arrives at your door that you know you have it. Some truck 1,000 miles away brought it, but you weren't pulling the truck along a wire to make it arrive. Things are inherently disconnected in the real world. The days of quickbasic are gone ha ha ha.
____________________________________________________________________________________
The Vulcan Science Directorate has determined that time travel is impossible.
|
|
|
|
|
I'd say that the best way would be to avoid rewriting the entire application. I imagine that your application consists of multiple, smaller modules that interact?
How about adding functionality that allows interaction over the web, without ditching the desktop-application? What starts with writing a webpage to retrieve/modify configuration-settings could very well grow into a separate interface over time
I are Troll
|
|
|
|
|
Right, continue the evolution.
Any ideas what may be the best technologies to use? This WebMatrix looks promising.
____________________________________________________________________________________
The Vulcan Science Directorate has determined that time travel is impossible.
|
|
|
|
|
Where are you storing your data in the desktop-application? If you already have Sql Server, you'd only need a webserver that's capable of running ASP.NET. I'd go this classic route, but only because I'm familiar with it. I haven't tried the WebMatrix package (yet), but does look like a good place to start.
It contains a webserver, and Sql Compact. That setup might not support stored procedures, and other Sql Compact limitations would apply.
I are Troll
|
|
|
|
|
Thanks again Eddy!
The back end is sql server, mostly express, and has some stored procs.
The whole webserver thing is a big black hole to me, which is part of why I posted the question. I haven't been following all the best practices, etc. But one big concern is that I want my customers to be able to use it with whatever system they currently have. E.g. if they're not running IIS, I don't my app to be eliminated on that basis.
I see what you mean about WebMatrix. It may not be suitable. But I get the impression we may see more of this kind of "grouping" of products to hopefully "simplify" the whole issue of "making your windows desktop app work on the web".
I think from the answers I have received so far, we are not "there" yet. 
____________________________________________________________________________________
The Vulcan Science Directorate has determined that time travel is impossible.
|
|
|
|
|
BobishKindaGuy wrote: I haven't been following all the best practices, etc.
That means that you're talking about a business-application, not something that specifically designed to be used in a text-book for a cs-class. Code grows, and usually the amount of best-practices used therin do so to.
BobishKindaGuy wrote: But one big concern is that I want my customers to be able to use it with whatever system they currently have. E.g. if they're not running IIS, I don't my app to be eliminated on that basis.
Good point. I'm running an Apache webserver, with Mono. Serves ASP.NET code quite nicely, at no cost. A nice extra is that you can brag on being compatible with Linux
BobishKindaGuy wrote: But I get the impression we may see more of this kind of "grouping" of products to hopefully "simplify" the whole issue of "making your windows desktop app work on the web".
Ever heard people complain on the price of Office? A grouping of products is often perceived as a single product that happens to consist of different parts.
I'm looking forward to meet a decent follow-up for Microsoft Access. WebMatrix sounds like it may come close to that 
I are Troll
|
|
|
|
|
Eddy Vluggen wrote: I'm running an Apache webserver, with Mono. Serves ASP.NET code quite nicely, at no cost. A nice extra is that you can brag on being compatible with Linux
YES!
Thanks for that. I didn't know about that.
One more piece of the puzzle is in place.
____________________________________________________________________________________
The Vulcan Science Directorate has determined that time travel is impossible.
|
|
|
|
|
When the app is well-structured into several layers (UI/presentation, business logic, data access), you could reuse most layers unmodified, and simply modify/add another presentation layer. If it isn't well-structured yet, now is the time to spend the effort.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
