I'm working on a little MVC framework and I'm wondering what the "best way" is to structure things so secure pages/controllers always ensure the user is logged in (and thus automatically redirects to a login page--or elsewhere--if not). Obviously, there are a lot of ways to do it, but I'm wondering what solution(s) are the most common or are considered the best practice. Some ideas I had:
Explicitly call user->isLoggedIn() at the beginning of your controller action method? (Seems far too easy to forget and leave an important page unsecure on accident)
Make your controller extend a secureController that always checks for login in the constructor?
Do this check in the model when secure information is requested? (Seems like redundant calls would be made)
Something else entirely?
Note: I'm working in PHP, though the question is not language-dependent.
ASP.Net MVC does this nicely with the [Authorize] attribute on the controller class which needs authorization
It isn't the only way to do it, but...
All client requests go to a FilterManager, which builds a FilterChain based on the details of the request. Within the FilterChain, if the resource is one that requires a logged in state, and the client isn't logged in, the request can be redirected. The original request can be saved and redirected to the log in page, allowing continuation from the original request (this is optional).
It's a J2EE design pattern, but you can implement it in any language once you get the idea. In this case, one of the "filters" is an "authentication filter". See http://java.sun.com/blueprints/corej2eepatterns/Patterns/InterceptingFilter.html for details of the idea (in Java).
The advantages of this is that all pages will centralize their logic in the FilterManager, so a page need only have their call to the FilterManager. Additionally, you can add debugging filters / logging filters / etc which can assist in maintaining / developing your code.
Related
I am doing a Spring web application with many forms. A common practice when a form is successfully saved is saving a success message in session and then redirecting the user to the same or new link where the success message is displayed.
In Spring web, this can be done like the following:
request.getSession().setAttribute("successMessage", "Form saved successfully");
return "redirect:new_link";
I am hoping to make my application stateless but still follow the practice of redirecting and showing a form-save-success message. I am hoping to have an elegant solution. A simple (but I feel not elegant for a few reasons) solution is to attach the message as a string in the returned url similar to the following and let the front-end page to detect and display the message.
return "redirect:new_link?successMessage=Form-saved-successfully";
I think any idea or solution applies to any web applications, regardless of platforms used or programming languages.
Any input is really appreciated.
Thanks and regards!
Use the Post-Redirect-Get pattern
Use Flash Attributes to show Success/Failure messages on subsequent pages.
Assuming you use Spring 3.1 or up, then you can use flash attributes for that purpose. Define a method attribute of the type RedirectAttributes. The javadoc have a sample on how to use them.
Although this doesn't make your application stateless, it removes the direct couling to the session. (In theory you could implement your own FlashMapManager as the default still stores it in the session).
If you want a stateless solution either you need to put the message (or a message code) in the redirect URL or redirect to a specific 'Your-Form-Was-Saved' page which always shows the same message.
I'm trying to comprehend the concept behind MVC and URL routing. I understand that it's good to seperate your code, hence MVC, but fail to understand the idea behind the URL router!
Instead of having a lot of rewrite rules in htaccess, I send all traffic to router.php, and in this page I have an array with page urls, and its corresponding PHP controller.
To keep it simple, I just include the controller, where the output finally is generated, however having seen lots of other practices, I'm afraid that im doing something wrong, or bad in some way..
Can someone please enlighten me, how to do a good, but simple URL router? Is it okay just to include the controller, which then generates the output? Perhaps someone has some information that describes the subject in details (something understandable for a beginner)
Thanks in advance
There are lots of ways to do URL routing. Some are client side like with backbone.js, others are server side. Doing it with .htaccess is one way, another is th way you are doing it by having a prerequisite path that is is either a hard path, or a regular expression that you parse and figure out where to send it. None of them are 100% right or 100% wrong, it's all preference, and it sounds like you are doing just fine with a route file.
For more information on how different frameworks do routing you should read over the docs on routing for CodeIgniter, and Symfony frameworks to see 2 different styles of server side routing, and then maybe look at the backbone.js framework for client side routing just to see the similarities and differences.
The router in the MVC concept decides which controller it has to load when a user requests a page. E.g. a user requests example.com/something/very/important, the router would now look for an action which is mapped to this route and execute it. There are different methods how you can accomplish that (simple include, instantiating a class and running a method etc.) but the most simple and still powerful solution I came up with is creating a separate class for every action. I've written a little article on that matter, since I've been asked this question several times, you can have a look at it here: Writing a simple and fast mvc router with PHP
The ASP.NET Routing module is responsible for mapping incoming browser requests to particular MVC controller actions.
Routing is a pattern matching system that monitor the incoming request and figure out what to do with that request. At runtime, Routing engine use the Route table for matching the incoming request's URL pattern against the URL patterns defined in the Route table. You can register one or more URL patterns to the Route table at Application_Start event.
I'm using urlrewriteFilter (org.tuckey.web.filters.urlrewrite.UrlRewriteFilter) to forward pages like www.mysite.com/myname to a Struts2 action. The action is mapped up in sitemesh, and it works properly.
But now I want to keep the same URL but apply another decorator to the page, based on whether the user is logged in or not.
I'm using AppFuse-stack Struts2.
Ok - since no-one else looks like having a go.
Sitemesh selects the decorators based on the incoming url string, so to have different decorators you need different urls depending on the login status of your client. AFAIK Sitemesh uses the entire Url string so this includes parameters so you might get away with appending ?loggedIn="true" or ?loggedIn="false" and map the decorators on this. However this doesn't help with POST requests.
Another way to do it would be to create two Struts packages - one for logged in users and one for anonymous users so your actions will have different paths and then map on the path part of the Url.
I don't know how practical this might be in your scenario, but a third option maybe to have one common decorator and control the layout via seperate stylesheets which you could control via a test in your jsp.
HTH
Regards
I have a custom [AuthenticationFilter] which simply redirects users that are not authorized to access administrative content.
I apply the filter to
[AuthenticationFilter]
public ActionResult Index() {}
But, I also have
[HttpPost]
public ActionResult Index(HttpPostedFileBase file) {}
for handling file uploads. Do I need the attribute here?
My gut instinct tells me no. There's no way to POST a file to the page because uploadButton is blocked from loading by the first method.
The only other security concern I can imagine is a cross site AJAX post, but this shouldn't be possible or at least is highly unlikely because its an intranet site.
So, is there any reason to apply [AuthenticationFilter] to the file handler?
You can never count on your client-side control (disabling the upload button) from stopping something from hitting your server. End users have complete control over what happens on the client. They can enable controls, remove or modify hidden fields, intercept browser requests, or bypass the browser completely and make their own requests (with any file they want).
Any place that you have the option to add security on the server you should do it. There is no type of request you can stop by simply using browser controls.
I believe it would still be possible for someone to send a POST using something like Fiddler. The effort to secure the method is minimal, so I would say better to be safe than sorry.
I'd turn the question around and ask if there are reasons not to apply the AuthenticationFilter to the method? As long as you know that there may be a risk for this method, why not apply the filter; unless you have performance issues with your AuthenticationFilter, go for it. In fact, if you know your whole controller is destined to be used by authorized users, apply the filter at the controller level!
I'm from a non-computing background and I'm struggling to getting my head around MVC design approaches and frameworks in general. I "get" code re-use, and separation of logic from display, and I "get" encapsulation and decoupling, but I don't get this.
At the moment I simply put everything in root, a separate subfolders for images, cfcs, and _includes, all database interaction via cfcs. I do all my processing at the top of the page, then a comment line then display/page layout below that.
Most of the frameworks I have looked at seem to favour a front controller, so my simplistic version of a top controller MVC design would be a subfolder for cfcs, controllers, and views and a big switch statement in index.cfm
<cfif not IsDefined("URL.event")>
<cflocation url="index.cfm?event=home" addtoken="No">
</cfif>
<cfswitch expression="#url.event#">
<cfcase value="home">
<cfinclude template="controllers/home.cfm"/>
<cfinclude template="views/home.cfm"/>
</cfcase>
<cfcase value="about">
<cfinclude template="controllers/about.cfm"/>
<cfinclude template="views/about.cfm"/>
</cfcase>
</cfswitch>
.. but what real advantage does that give me over a page controller design? Unless it's just the kind of sites I write, I always seem to find that the controller logic is specific to a view, its not like one controller could fit several views or several controllers could output to one view, so what would be the point of separating them?
The light hasn't come on for me yet, any pointers?
By "top" controller, I think you mean "front" controller, a single point of entry for requests into an application. As #bpanulla wrote, most ColdFusion frameworks use this design pattern. This becomes particularly interesting with URL rewriting, where it becomes easy to have search engine safe URLs by intercepting the a URL (e.g. domain.ext/i/am/friendly.ext) and routing it to some standard file such as index.cfm while making the requested URL a parameter (often as a request header). This also makes site redesigns where URLs change easier because it lends itself well to aliasing or redirects.
As far as controllers are concerned, they are usually tightly coupled to a particular URL or URL pattern. It's possible be more loosely coupled with controllers, but in practice I find that's an emergent property after multiple refactorings. What should be underlying the controller is one or more calls to a service layer that talks to the database, executes business process, creates stateful entities, etc... Then the controller receives the service layer's outputs and places them into whatever mechanism (e.g. an event object) is used to pass data to the view(s).
It's the service layer that's meant to be reusuable not the controllers. The controllers are merely an extension of whatever framework an application works within. The idea being that you should be able to switch frameworks with very little impact to the views and service layer. The piece that needs to be touched are the controllers.
So a given service object in a service layer should be able to service multiple controllers. For example, consider showing a logged in users' information as a widget on a site. There might be different pages served by different controllers, but each would call the same service object to get logged in user data that presumably might be given to the same view that renders the widget.
Update: Front Controller Advantages
Security: centralized authentication and authorization.
i18n & l10n: inject the right language pack into the request globally
Process Orchestration: think multi step checkout process for a shopping cart where you don't want the back and forward buttons to work - by routing everything through the front controller you're able to enforce what step (i.e. the state)
Logging & Tracking: easily add Google Analytics or other request tracking to a site by making the addition in just one place
Error Handling: centralized behavior
Now many of these items can also be done using <cferror> and Appplication.cfc, but I find it easier to have one centralized point.
Useful Links
http://java.sun.com/blueprints/corej2eepatterns/Patterns/FrontController.html
http://msdn.microsoft.com/en-us/library/ff648617.aspx
You actually implemented the crux of Fusebox (http://www.fusebox.org/) with what you wrote. There's nothing wrong with that, and most of the ColdFusion community used something similar to that for many years - Fusebox was the most-used CF framework (in my experience) until just a few years ago when ModelGlue, Mach-II and the other second generation CF frameworks came about.
One thing I can point out is that your approach to controllers (as .cfm files) actually does not enforce encapsulation in the typical OOD fashion, with specific arguments going to an object method call. Unless you are extremely dilligent, over time your .cfm controllers may wind up accumulated a large number of undocumented parameters that alter behavior to solve one problem or another.
With the various frameworks you also get nice features like Application, Session, and Request specific code (onApplicationStart, onRequestEnd, etc). But you can always get those through a simple Application.cfc.