I've built a SharePoint user control (not a web part) and am deploying it via Solutions, Features, etc.
It's a commercial component and I want to be able to store license information once it's registered. I've got all the licensing stuff down and working, however, I am trying to find a "global" (i.e. farm level) place to store the information (so it works on multi-server farms).
This is intended to be a commercial component so I have no control over security policies, application pool accounts, etc. I need it to work without admins needing to reconfigure their farms.
I've considered:
Web.config - best option so far, but have read that Windows UAC can interfere and changes may not always be applied.
Hierarchical Object Store - Several security gotchas - Namely app pool needs access to Config database (which many environments won't allow)
Root site property bag - Possible. I can update all the Root Sites Properties at the time of registration, but what happens when new web apps are created? User has to register component for each web app?
Registry, file system - Not persisted across servers
Custom DB - Seems like a lot of places for this to fail.
I know other commercial vendors are doing it somehow.
Any ideas?
Web.config - best option so far, but have read that Windows UAC can interfere and changes may not always be applied.
There are many many different opinions about putting your configuration stuff in web.config. Personally, i would NOT recommend it, because SharePoint is automatically pushing changes to it and you can't really control what's going on.
I've had similar requirements, but at a SiteCollection level. What i did was creating a simple custom list with 2 columns (Key, Value) at the root of my SiteCollection. Within my code, i hardcoded the name of the list and used elevated privileges (because i set the list permissions to admin-only) to access the values i needed.
You could basically do the same, but not at the root of the SiteCollection level, but in the Central Administration. This way, you can access the configuration list from anywhere within SharePoint.
Another idea would be setting up a simple configuration database and then use a custom web-service (which is deployed within SharePoint) to get it's values. However this adds quite a lot of overhead to such a "simple" task and will get you in a lot of trouble without proper exception handling/logging.
Related
I am authoring an installer that creates a new website and application pool. This installer is for internal use within several development environments which all have subtle differences. One may use only HTTP, another only HTTPS and one might use both. One might use the default ApplicationPoolIdentity identity where as another may use an explicit User reference.
Given the association of a WebAppPool is by ID through a WebApplication which must be nested under a WebSite, each time an option is desired on the installer, the breakout and duplication of features gets ridiculous.
I imagine I am not the first to encounter this, how does one accomplish this much flexibility within an installer?
The route I went with was creating a basic template within WIX using expected IDs, then used an immediate custom action scheduled before InstallValidate which manipulated the template entries to what ever degree was required. The properties used by the CA to make the decisions are stored in the registry for modify/patch/removal invocations.
I am starting to play with Orchard's multi-tenancy options to enable a single codebase to host dozens of websites (perhaps over a hundred in the future). The pieces I'm unclear on with this are:
Is it possible to call one or more API endpoints to dynamically create these sites from code on my end? Meaning, we have an existing codebase (non-Orchard) in .Net so what API(s) would I call to create these sites on the fly without having to login and do it manually?
In conjunction with #1, are there API(s) for us to create the individual users for the newly created sites that have a pre-configured set of minimal permissions (create content, deal with media, navigation) and blocking others (settings, user management, etc.)? Our client base for this process is not particularly computer savvy so limiting what they can break will go a long way in saving our support staff having to fix stuff they shouldn't be accessing to begin with.
Is there a way to handle SSO within these multi-tenant sites? The difficult part here would be our site relies on Session variables for access (it's a hybrid of classic ASP and .Net that I'm trying to modernize, but have to leave things like Session in for all the old stuff to work)? I'm guessing this would get into building a module, but know that's a rather advanced process so I'm trying to avoid it if possible.
Thanks in advance!
Yes, but Orchard doesn't easily integrate into existing applications. dotNest is an example of Orchard sites being created dynamically: http://dotnest.com/knowledge-base/topics/lombiq-hosting-suite
Yes. Users can be created from code, and you can assign them restricted permissions, the simplest way of doing it being to create a group with that permission set, and to put those users into that group. All of that can be done from code.
Just use oAuth like the rest of the world.
Just forget about integrating Orchard into an existing application. Especially classic ASP ;) Time to move on.
I am making a Sharepoint 2010 WebPart with functionality from another Main Web Application.
To develop the Webpart quickly I have imported the business logic assemblies used in the Main Web Application. The Webpart works and pulls application specific configuration information from the Sharepoint web.config file.
Is this the best place to store this information?
If not..
Where/How should the application specific configuration data be stored in Sharepoint?
The config data contains items like locations of web services etc. The data will only need to be edited by system administrators.
Thanks
Web.Config is, IMHO, a terrible place to store this sort of config information - its hard to deploy and hard to change, especially if you're using multiple web front ends.
The recommended way to do this is to use PropertyBag (key/value pairs) through the .Properties of SPFarm, SPWeb.RootWeb (for site collections), SPWeb, SPList etc (depending upon the scope that you need).
MSDN - Managing Custom Configuration Options for a SharePoint Application
There is a production ready code available as part of the
MSDN - The SharePoint Guidance Library
See Hierarchical configuration manager
This gives you programmatic access to read/write these values. If you want to do this without using the guidance library then you would use something like the following code.
SPWeb web = SPContext.Current.Web;
if (web.Properties.ContainsKey("MyProperty"))
string myProperty = web.Properties["MyProperty"];
If you want a UI to allow admins to easily set the values then use something like SharePoint Property Bag Settings
The easiest way to do it is to create sharepoint list visible only to administrator. It can have 3 columns description, title, value. It will store all config values. Also you can add a link to this list to site settings page.
The web config is always a good place. However if you want to change that data you will have to enforce some sort of site recompile which is a pain for end users.
Theres a nice little app/solution on codeplex to do with the property bag value
http://pbs.codeplex.com/
This is a brilliant little app/solution that ties in with your central administration.
It should be inbuilt i think.
Hope this helps.
I'm an experienced developer, but new to Silverlight, Prism, MVVM and all related stuff, and I have a need for a flexible approach regarding security in a new application I'm developing.
I have this security model implemented through a custom security framework I built for WinForms (actually Visual WebGui), but I need to get some guidelines on how to implement this for Silverlight or if there is something already built that I can use.
All modules implements two interfaces, ISecurableModule and ISecuredModule.
ISecurableModule is used to register modules with security repository.
ISecuredModule is used to enforce security.
In my Winforms app, at startup (actually after a new install, at first start), a module is started that through reflection inspect all assemblies, looking for modules implementing ISecurableModule interface. This interface reports if a module ce be started in Add Mode, Edit Mode, View Mode or None of them (e.g. a reporting module or data fetch / filter can be open only in View mode, as no data can be changed in it, but a data entry can be open only in Add, or in Add / Edit, or in View)
All this data is saved into security repository.
To define security rights, I can create security categories - that is, e.g. Inventory Operator, Inventory Supervisor, Payroll Operator, Payroll Supervisor, etc. For each category, I assign modules selected from security repository, with appropriate rights (e.g. for Inventory Operator I assign module Reception Inventory Operation or Transfer Inventory Operation with Add and View rights, and for Inventory Supervisor I assign all inventory modules with full rights)
Then I create Inventory Operator Role, and assign him the Inventory Operator Security category. I can assign several security categories to each role (because I can create security categories with a higher granularity - e.g. security category to manage own account or to manage group of users - which will be granted to supervisors, etc)
Then at runtime I have the concept of workplace (like shell in Prism) where I can load modules dynamically (really dynamically, I use ServiceLocator pattern to locate a component based on the interface it implements and then there is a controller for each class of module - modules implementing the same interface - which can use a enum field to identify which module to actually load for the time of data needed to process). The workplace controller uses a security provider which check the access rights for module to be loaded against the access rights for current user.
In my SL4 app I want to use MVVM pattern, and thus I want to have my views codeless and drive the whole functionality through ViewModel, ICommands and data binding. So I need some suggestions on how can I accomplish this sort of functionality I described into a SL4 app. I'm not particularly tied to Prism, so I will consider if there is another SL4 framework which can help me accomplish this goal.
You could try to protect the Silverlight application in many ways but in the end you cannot trust the client.
A couple of guidelines I use:
Protect the wire: use ssl to protect communication between SL and the back-end (perhaps even issue custom tokens to be able to invalidate a connection)
Do not rely on secrets in the Silverlight application (private keys, custom encryption methods, isolated storage) because they are easily broken
Put all important logic and security checks on the server.
Always check authorization when a receiving a (service)call; you never know who is calling unless you check.
I only use authorization on modules to reduce the download; if you are not authorized to use a module why download it?
To quickly summarise my question:
Is it feasible to programmatically change the name of a directory (with both files and sub-folders) in SharePoint? I am expecting that users will have files checked out on at least some occasions what I am attempting the rename.
The background:
I am currently contracting for a company that produces web based software (ASP.NET) with a configurable document management system. The system can be configured to use different underlying systems, with the most common environment being SharePoint (WSS 3).
I have been assigned a task to extend what has to now been a fairly simple system (simply output files into a fixed directory structure, occasionally read). Having never worked with SharePoint before I am doing some research on best practices, and am attempting to work out what is viable. At this stage I do not have access to a testing environment myself, so am limited to reading up online.
One request is to have the directory structure reflect the name (as one example) of the current client - so all documentation for a client will be in one place, and can be accessed externally via SharePoint or other compatible applications. The specification cites that if the name of the client changes then the directory structure should immediately update. My concern is that this will either directly cause errors (eg. Permission denied) or indirectly cause errors (loss of work for users who have externally checked out files).
As a follow up question if there are concerns with the above, is there a better way to implement the above? I have looked at suggesting the users use views to access the structure in SharePoint, however there is a concern from our BA that users will not be able to directly upload new files into this structure.
Thanks
The issue with Folders in SharePoint is that they are not really folders in the way you would expect of a file system. All files in a SiteCollection are stored in one big-assed table on the Database (checkout the AllDocs table).
I cannot categorically say it is safe to rename the folder without doing a bit of testing, I know that the folders "name" is not the key to accessing the document, despite it appearing to be based on the Url you see in the browser.
The best bet is to do a quick test, but I am pretty sure that your plan will not be a problem.
The potential issue is if any Content Query Web Parts etc rely on specific folders to exist or if any other "code" or "pages" look for that folder and not the folderId.
Save the content of the list before you "attempt" it in production. You don't want to loose data.
Checked out documents will still work the way you expect them to.
You may however have to run a crawl again.