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.
Related
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'm just learning how to develop an application for Sharepoint.
As far as I can see there are three types of integration into Sharepoint possible:
Sandboxed Solution (limited resource access but easy to install etc)
Farm Solution (installation only available from administrator)
Standard application (maybe .net MVC) with referencing the Sharepoint assembly to access the SPS functionality
Is that correct and complete or am I missing something?
There are quite a few ways to develop for SharePoint depending on your scope, requirements, etc. My knowledge is more in the SP2007 realm than 2010 and my answer reflects that.
JavaScript
Using Content Editor Web Parts you can customize the look of SharePoint, interact with List Data and do some interesting UI effects just using jQuery and the SPServices Plugin. These solutions don't require package and deployment.
Custom Content Type
These can be created through the SharePoint UI or defined through custom XML documents and deployed via WSP. Essentially these are just a collection of field definitions that are related in some logical way. Content types can be added to a list to have all the fields automatically available. In addition, they provide a convenient way of mixing and matching data in the same list (think of roll-ups or backing up list data) though I've never used them in this way.
Event Receiver
Event Receivers can be created to respond to specific events in SharePoint. If you attach an Event Receiver to a list, you can listen for and respond to events like an item or attachment being added, updated, deleted in both a synchronous (-ing) fashion - so you can implement validation and cancel the operation - or asynchronously (-ed) - to do some post-processing once SharePoint is done processing the item. Event Receivers are processed by the Front-End SharePoint server which handled the request which triggered the event. This is different than Timer Jobs and Workflows which are executed by any server in the farm that happens to be available.
Further, Event Receivers can be attached to lists based on their type (apply to all lists of this ID type) or they can be associated with a Content Type and become associated with a list that way (when the content type is added to the list, so too is the event receiver added).
Feature Receivers are a special kind of Event Receiver in that they respond to a Feature
being activated or deactivated to do some additional work. Many people refer to this extra work as Feature Stapling since it lets you perform additional tasks on-demand that couldn't otherwise be done using just XML documents.
Timer Job
A Timer Job is a piece of code that is run on a schedule. It's not executed in the W3WP process like Event Receivers are but rather via the TimerService. Because of this, certain features or values are missing from the SPRequest object. Developing Timer Jobs is more difficult and, in practice, more error prone, more difficult to debug, etc. than Event Receivers.
Workflow
Workflows can be created using SharePoint Designer or Visual Studio. The major difference between these are features available to you at design time. SharePoint Designer Workflows are easier to create and get going but tend to be buggy in SharePoint 2007. Further they are not easily packaged and deployed across environments but rather are associated directly to the list in which you created them (in 2007; in 2010 there is extended capability to allow packaging or even migration into Visual Studio for more complicated customization).
Using Visual Studio gives you more depth and capability but like Timer Jobs they are often difficult to "get right" and they are also processed by the Timer Service process.
Web Part
A custom Web Part is very similar to a regular ASP.NET web part with some extended capability within the SharePoint context. You have access to the SPRequest object and thus all the contextual information (current user, current list/web/site, etc.) to do your work. You can access external databases, make use of most ASP.NET controls, etc.
Custom ASPX Page
If a Web Part isn't sufficient for your needs or you want control over the full page, you can create SharePoint-enabled web pages. These are standard ASP.NET pages decorated with the proper SharePoint master page and deployed into a subdirectory of the hive LAYOUTS directory. With this you have similar access to the current request state as with a Web Part but you have more control over the entire page render.
Custom Web Application
If you have need for a standalone application, you can still take advantage of SharePoint's authentication and authorization tools without running directly in its context. To do this, create an IIS Web Application and set the Application Pool Identity to the same as SharePoint. Alternatively you could make a virtual directory within your SharePoint application pool but this is generally not recommended. You will still be constrained to using the .NET Framework 2.0 runtime if you want to use the SharePoint Object Model at all. This setup seems rarely used in the field since most of the time you can accomplish your needs by just using custom ASPX pages or web parts.
Regarding your specific questions:
Sandboxed solutions are just a special type of solution that restricts the namespaces your web part, etc. have access to. For instance your code can't reach out to access lists outside of its permission area. It can't send email on your behalf. You can increase your rights by using custom permission sets but this is an advanced topic. I just wanted to point out "sandboxed solution" isn't a type in and of itself, it just describes a restriction where previously none existed (SP 2007 GAC-deployed solutions).
Regarding your question regarding an MVC application using the SharePoint Object Model, like I mentioned you are still restricted to running in .NET 2.0 runtime.
EDIT: I forgot (at least) one more option!
List Service / Other ASMX Services
SharePoint has a number of web services you can consume to interact with Lists among other things. In this case, your application can be developed using any technology (or runtime!) you wish as long as it knows how to consume the ASMX services. The functionality available isn't as rich as using the Object Model directly (which is why I often forget to consider it) but it does allow your code to be more decoupled from the SharePoint environment itself. In 2010 there are a lot more options for Client Services to provide even greater functionality.
For developing a solution in visual studio you can go for Sandbox solution and farm solution. If you are having SharePoint 2013, then you will have another better option which is App Part development.
Since Sandbox solution is depricated from SharePoint 2013 onwards, i suggest you should not go with Sandbox solutions. Better to go with App Part development.
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.
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?
I understand the pros of using namespaces within the actual application layers but when it comes to the front tier, I am not so sure.
My project is a Website (not WebApplication) and I get all sorts of problems (missing references, for one) when I try and include "namespaced" user controls. Despite explicit declarations in web.config under system.web - pages - controls - add.
When it comes to the actual views, the webforms: when you create a new page, Visual Studio creates the codebehind classname from the path where you chose to create the file. So most times, I'd say that class names will be unique. If you move around pages, then it will become strange to see say Start_DefaultPage but under another sub folder.
To summarize: Is it recommended to put namespaces into the web tier? What are the pros and cons?
Yes. In the future, you may decide to include external libraries that (coincidentally) use the same class names, and you do not want to have a namespace collision, as you very well know can occur. In addition, you may have web applications in a virtual directory that will inherit the properties outlined in the parent web.config. You do not want to mess with namespace conflicts there, either. Generally speaking, it is just a good programming practice.
Your problem is that you are using a web site "project". Stop doing that, and you'll stop having these problems.
Web Sites are a mistake that Microsoft made. There's no need for you to make their mistake into your mistake.