I notice routes.IgnoreRoute("{resource}.axd/{*pathInfo}"); is always setup whenever we create MVC applications.
If it is a mandatory thing, why don't we setup it once through IIS settings rather than doing it again and again ?
Nobody said it was 'mandatory'. It makes excellent sense to be there by default, though. And if you don't want it, you can remove it.
Related
In Sails.js you can easily create an api and this will provide you with action, rest and a shortcut api. This is wery clear from a lot of sources on the internet. This is also very practical when setting up a new app.
One thing that don't seems very clear is what to do when deploying the application to production. I can't think of anyone who would like /user to be open for anyone to see...
I don't really know how to handle this, there is many routes that one might not want to be open in production. I can think of the following ways to solve it:
close rest, actions and shortcuts in blueprints.js (which will remove all automatic apis), and then define them myself in routes.js.
Add policies for every route that I want no one to see (I don't even know all the routes that is automatically created so this seems risky).
Override all controller actions that should not be visible.
What is the right way to handle the routes that I don't want to have, when they are automatically created?
I don't like only your 3-rd method. I can suggest few methods:
Disable rest for all models in global blueprints configuration (config/blueprints.js) and enable it in needful models. Look overriding blueprints.
Yes, you can add policies to some blueprints. You can find list of all default blueprints ("routes that is automatically created") in blueprint-api reference.
Hope it helps you. Sorry for my english :)
Is it possible to get the Portal base URL (like http://www.thisismyportal.com) from a Portlet using Portlet 2.0 API?
Right now I'm planning to manually build it concatenating PorletRequest.getServerName(), PortletRequest.getServerPort() and PortletRequest.getContextPath(); but it seems kind of clumsy (and there's no PortletRequest.getProtocol())
While it is clumsy, it is the safest way to construct the URL; and while there is no PortletRequest.getProtocol() method, you can conclude the protocol using the PortletRequest.isSecure() method.
I would advise against using an external configuration for the base URL, for a couple of reasons.
First, it would be yet another configuration item for you to maintain across environments (test, integration, production and so forth). There's very little justification to hold, in configuration, something that is fully reproducible using the current request.
Second, under certain circumstances, it might be impossible to designate a particular URL as a "base URL" for the portal. An example would be the case in which the portal server is associated with multiple hosts, or multiple host aliases.
We had those configuration properties in Resource Environment Provider for the purpose of generating external URLs for sending them in emails. It was specific solution and it wasn't a problem for us as we had other properties stored there as well so we knew it will be available at runtime. I don't know if that suits your needs. It depends on your scenario.
Also, we used https only during login, so we always generated http URLs.
Hope this helps.
We are considering purchasing DotNetNuke (or Sitefinity) on pretty short notice and there are is a question I have that I am having trouble finding a quick answer to. (I have a separate but similar post with Sitefinity as the focus, if you can answer that better or in addition.)
We are currently not using any CMS at all and we have some custom development that will not go away just because we go with a CMS for some or most of our site.
Our custom development is c# ASPX with Site Master and nested Site Master pages. These custom apps do not own their own top level in our web site, but are part of a branch, typically one or two levels down (for example, http:www.contoso.com/branch/app/default.aspx).
How is DotNetNuke typically configured in a CMS/Custom “mixed mode”? For example, is DotNetNuke installed at the “top” of the web site, or “where needed” down in the web site.
How does this relate when mixing CMS and custom web applications?
Does the CMS interface allow for adding these custom apps or do you just go to the web server and add them to the structure?
It appears from reading other posts, we can create our own custom c# modules and have CMS editors “drop in” the modules on the pages. Can someone confirm that for me?
If I did not provide enough detail, please feel free to ask for more.
DNN is most commonly installed at the root of the website, but that is not required. It is sometimes run as an application in a virtual directory that is part of a larger site.
It is possible to add .aspx pages at the correct location within the DNN. The UrlRewrite handler will initially look at all such requests, and assuming that existing pages, and friendly url handlers don't think they "own" the .aspx page, DNN will stop processing the request and hand it to your page. There is no specific way to "register" these pages with DNN. I wouldn't generally recommend this approach, but it does work and can make sense in specific situations.
Alternately, you can write your own DNN modules. Existing code, can usually be quite easily be adapted by converting the code to work in .ascx user control that inherits from PortalModuleBase. Code that wants to take advantage of core DNN features e.g. membership or permissions will of course need to be modified to use the DNN APIs.
The DNN module approach is generally the best option. But the details of your situation may make one of the other approaches more appropriate for you. Basically as long as your site is layed out so that it is clear which requests are destined for DNN and which are not, you can mix and match with other asp.net code as needed.
One thing that causes trouble in a mixed configuration is configuration inheritance.
If DNN is the root application, you'll either have to remove problematic http modules and handlers in the application's web.config or disable inheritance with a location setting in the DNN's (root) web.config:
<location path="." inheritInChildApplications="false">
<system.web>
...
</system.web>
</location>
Maintaining the inheritance between application's web.config and DNN web.config is fragile.
Changes in DNN web.config can cause the application in the virtual directory to fail. In addition to removing each http module and handler, you'll need at least to add DNN's App_Code directories to the application configuration.
On the other hand, location setting does not always play well with DNN modules, especially if they have aspx pages in addition to controls inheriting from PortalModuleBase. Personally, I've never got the location setting work well enough with DNN.
See also
How to disable web.config Inheritance for Child Applications in Subfolders in ASP.NET?
How do I stop web.config inheritance
Avoid web.config inheritance in child web application using inheritInChildApplications
What's the recommended way to do HTTP redirects on Plone using Python? What hooks are available? Can redirects managed through ZMI? My guess is that there is per site pre-traverse mechanism which allows you to check URL and intercept the request if it looks a redirect is needed.
We have some complex redirecting rules and it does not make sense to put them to Apache/NGINX.
Maybe you can do something with: http://pypi.python.org/pypi/plone.app.redirector. RedirectionTool uses this technology to allow TTW management of content that has been renamed in Plone. But I assume you could use it for whatever complex redirects you need to do in Python.
There is also:
http://pypi.python.org/pypi/collective.fourohfour (middleware)
And:
http://pypi.python.org/pypi/collective.redirect (which looks interesting.)
I agree it might be nice to have Plone handle redirects that are not strictly related to content (assuming this is what you mean by "complex redirecting")
not sure if http://plone.org/products/redirectiontool/ is the same as http://pypi.python.org/pypi/Products.RedirectionTool. the changelog and releasedates look different. it might be worth a try
In the end this was the code I needed:
http://opensourcehacker.com/2011/08/03/python-based-http-redirect-rules-with-plone/
Unfortunately none of existing add-ons allowed to write redirect logic in Python in such simple manner.
If you're not allowed to install anything new, you can use the underlying Zope to create a redirect via a Python script, see details.
I see a lot of articles and posts on how to create a custom MembershipProvider, but haven't found any explanation as to why I must/should use it in my MVC2 web app. Apart from "Hey, security is hard!", what are critical parts of the whole MembershipProvider subsystem that I should know about that I don't, because I've only read about how to override parts of it? Is there some "behind the scenes magic" that I don't see and will have to implement myself? Is there some attribute or other piece of functionality that will trip over itself without a properly setup MembershipProvider?
I am building a web app, using a DDD approach, so the way I see it, I have a User entity and a Group entity. I don't need to customize ValidateUser() under the provider; I can just have it as a method on my User entity. I have to have a User object anyways, to implement things not under the MemebrshipProvider?
So, what gives? :)
No, you don't need it. I have sites that use it and sites that don't. One reason to use it is that plumbing is already there for it in ASP.NET and you can easily implement authentication by simply providing the proper configuration items (and setting up the DB or AD or whatever).
A RoleProvider, on the other hand, comes in very handy when using the built-in AuthorizeAttributes and derivatives. Implementing a RoleProvider will save you a fair amount of custom programming on the authorization side.