I am making an application that supports different user roles so I need to be able to closely control which users have access to certain functionality. Is there an easy way I can do this in SoapBox Core?

asked 19 Oct '10, 22:28

KarlB's gravatar image

KarlB
576202136
accept rate: 0%

edited 21 Oct '10, 20:10

Scott%20Whitlock's gravatar image

Scott Whitlock ♦♦
696262833

I'm removing the feature-request tag here, but I'll add a note about this to a central add-in manager feature.

(21 Oct '10, 20:10) Scott Whitlock ♦♦

You could use MEF Metadata and use the:

Lazy<T,M>

...syntax. You can then query the metadata about the Add-in object before you instantiate it. You could embed access requirements in the metadata.

link

answered 21 Oct '10, 19:49

Scott%20Whitlock's gravatar image

Scott Whitlock ♦♦
696262833
accept rate: 50%

The approach Scott mentioned above is great. I looked into it a little more and found this article that provides a bit more detail in case anyone else is interested:

(18 Feb '11, 11:03) KarlB

Here’s how I've tried to do it. Let me know what you think:

Inside the bin folder for the application I created two sub directories, one called something like ‘UserAddins’ and the other called ‘OffLimitsAddins’. When a user logs into the application I use whatever method I like to verify their identity and determine which add-ins they are allowed to use. Once I know which add-ins the user is allowed to use I copy the corresponding dlls to the ‘UserAddins’ folder, then I copy the rest of the dlls to the ‘OffLimitsAddins’ folder. Then in the part of the code that composes all the parts in the application I added the “.\UserAddins” folder as a DirectoryCatalog to the AggregateCatalog that then gets composed.

This approach has worked, though I can’t say it has always worked well. First off to actually do this I had to make the user log-in screen its own application that then launches my SoapBox Core application once user identification is complete. Then, I had to create some dummy extension parts that corresponded to place holders for when certain add-ins were not allowed for certain users. These dummy add-ins where never very complicated, but they are still code that I now have to maintain.

Though this idea works and has some high points, I am sure there is a better solution to this problem out there. Maybe you know what that solution is? Please leave a comment if you have thoughts or suggestions.

If people like this idea, then maybe we can find a way to distribute a cleaned-up version of my implementation (or something like it) as an add-in that exists outside of the SoapBox Core releases? What do you think?

link

answered 19 Oct '10, 22:30

KarlB's gravatar image

KarlB
576202136
accept rate: 0%

Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "Title")
  • image?![alt text](/path/img.jpg "Title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Tags:

×1
×1

Asked: 19 Oct '10, 22:28

Seen: 2,483 times

Last updated: 18 Feb '11, 11:04

Related questions

powered by OSQA