I am playing with learning ASP.NET MVC as a non-web developer. I am trying to find the best idiom to use for an app that has a concept of selecting a 'project' to work on the first page that affects all other pages.
There seems to be three choices:
Just put the information into the session state. Works fine, but isn't very MVC-ish
Embed the state into all URLs ... so instead of /Products/Details/1 the URLs are all /(project_id)/Products/Details/1
Setting a separate cookie for this information
Since nearly all the URLs in the application would require the current project this seems overkill, and makes constructing the URLs used in any of the views that much more work. It would also require that I validate the permissions on each call since the user could easily modify it.
Any suggestions on the best approach -- is using the session such a bad idea?!
Option 2 out of yours is my choice.
So instead of /Products/1/Details
I would make it Project/1/Products/1/Details
Its just more in line with REST. Its virtually irrelevant to MVC, but if you want your Routes and URLs to read like resources in REST, you'll want the url to collapse at the slashes and carry the state. Other ways are to mark a project id in cookie, but that kills linking, so that as someone leaves and comes back they get put back there.
Session also makes it hard to test if you bind yourself directly to that concept.
Personally, I would just use the session. There's nothing non-MVCish about the session really - think of it as just being part of your model.
Using a cookie is really no different than using the session. Embedding it in the URLs is not a bad option though, especially for "linkability" if that's a concern for your project. But it has the side effect of cluttering up URLs and requiring you to pass that ID around constantly from page to page.
Related
I've created an Orchard Website that consists of many mini-websites made operable via theme selection relating and triggered by the current [unique] URL all from the same DB.
It works as I'd hoped, but I wish to improve the Autoroute paths of my pages.
Currently I'm using:
{Content.Fields.PageOrderPart.SitesTaxonomy.Terms:0}/{Content.Slug}
Which results in:
www.site1.com/sitealpha/gallery
www.site2.com/sitebeta/gallery
What I would like is:
www.site1.com/gallery
www.site2.com/gallery
However, I still need to be able to differentiate pages with the same name [...hence why the Autoroute path above was created in the first place] - or I will obviously get permalink duplication errors.
Can anyone think of an ingenious way to sort this or is there some Orchard feature I may've missed, perhaps url rewrites or possibly an existing MVC method?
Many thanks for your input, PP
Further thoughts (hopefully this doesn’t influence any other member's sugestions):
Rewrite rules: Probably aren't dynamic enough for the amount of content I have [still increasing] - and I could see any alterations to existing permalinks being a real nightmare.
Besides, for an unkown reason - I and some other Orchard users - can't seem to get a rewrite action to work?
Routes: Honestly, I haven't played with these properly - I can see that capturing and dissecting a URL to stipulate the area / controller / action should be easy enough - but I'm not sure how to go about redirecting to a particular Orchard page?
FilterProvider, IActionFilter: I tested this scenario [which could become quite complicated code wise] and I'm not sure the performance is acceptable -- my dev system seems to really suffer with any code in the 'OnActionExecuting' method.
Update: I've investigated the IActionFilter scenario and it appears my initial performance worries were unfounded [i.e. a fresh install didn't behave any slower with some URL restructuring code on the 'OnActionExecuting' method].
My last hurdle is to discover why IIS Rewrite rules aren't working with Orchard:
https://stackoverflow.com/questions/35226580/orchard-cms-iis-rewrite-rules-do-not-work-for-rewrite-action-types
It could be that multi tenancy would be the feature you are after. You can have one code, one db but they are all completely separate sites. So separate admin areas etc.
http://docs.orchardproject.net/Documentation/Setting-up-a-multi-tenant-orchard-site
My group is working on a new web application and is considering using MVC. However, there are members who would rather include pages than use master pages. Is this possible to do in ASP.NET MVC? In the small amount of time that I've poked around with MVC I have not yet been able to figure out how one might accomplish that.
Why the preference?
Having used both in the past, Master Pages are much easier to use. You just have to get over the (very small) learning curve.
ASP.NET MVC doesn't force you to do either one though...
If you like the Include method, then you would probably feel most comfortable using Partial Views to provide the same functionality. You would just add the Partial Views to each page instead of including another page.
No. It does not force you in any way.
You should really avoid server-side includes with anything newer than classic ASP. They're more difficult to debug, IIS has a hard time finding correct line numbers when there's a problem, etc. Also, I haven't looked at the order in which SSIs are processed in the request pipeline - they may not work at all with ASP.NET.
If you're moving into MVC, use RenderPartial() or RenderAction() instead. These perform essentially the same function as a server-side include, but are more inline with the spirit of the framework and provide some additional benefits, like passing models without having to declare a global variable (which should also be avoided, and I'm not sure if it is even possible under .NET scope rules).
And, no, master pages are not required, but you really should use them. Using includes to build your page layout works, but only if you don't and won't need to radically change the layout of your site at any point in the future. I'm in that boat now with a 350k line classic ASP app which used very nicely structured code and #includes to create the page layout. That was the best solution available at the time, but it's causing me a lot of headaches now (10+ years later).
With a master page you can move your ContentPlaceHolder blocks anywhere you want, whereas with #includes the final page really determines the format by the order in which the includes are placed. This also makes it pretty straightforward to create a mobile version of your site - you can create a mobile-specific master page and use the same content views.
Its a matter of choice,but for consistent look and feel across the web application, master pages give you just that. You have to take the team through the learning curve of good master page design, not only would it be useful for the current project at hand but also future projects. Good luck!
I would rather opt to go for Master pages due to the ease of use and built in support in MVC for this.
If you want to know more about it check out this tutorial: Creating Page Layouts with View Master Pages.
Grz, Kris.
I have an application written in MVC that uses your regular .Net Forms Authentication. There's nothing particularly new or exciting going on with it.
My client has now asked that users be able to log in to the app on the same machine but in different browsers, or different tabs within the same browser. To my mind, he's asking for a scope change to have authentication moved to cookieless instead of its current design.
Not having had any experience with doing this in MVC, I'm curious to know before I get started how much hurt I'm in for by trying this. Are there better ways to do it? What should I consider?
Any advice appreciated.
in different browsers
This should be easy because different browsers do not share cookies.
or different tabs within the same browser
That's a little bit more difficult, because the same cookies are used browser-wide, so there is no difference between the tabs.
You can try adding some authentication token to all links like:
http://site.com/home?token=afdaewdf4393cffjedcifa
http://site.com/account?token=afdaewdf4393cffjedcifa
and so on.
It's relatively easy to have the same parameter in all MVC-generated links, because the same parameter is automatically copied into other links as the user navigates between views (MVC by design).
What is the best and cleanest way to implement A-B testing in asp.net mvc? That is, when we make new changes to an asp.net mvc web site, we want to test the new html/css/js with a certain subset of visitors (defined on cookie, login id, etc) and then analyze some metrics (page response time, number of pages visited, $$$ in sales, etc) afterwards to measure the level of success of the changes.
I am looking for a clean way to implement a way of choosing what view (html/css/js, etc...) to render using asp.net mvc.
Check out FairlyCertain (http://www.fairtutor.com/fairlycertain/) when you get a chance. It's a .NET A/B library that you can pretty much just drop into your project and start writing tests.
Unlike the Javascript libraries from Google and VisualWebsiteOptimizer, everything happens on the server so you don't suffer any performance, user experience or SEO issues. I've been using it in my stuff for a while now and it works quite well.
There is an A/B testing framework specifically for ASP.NET MVC. This is an open source software I wrote myself when, just like you, didn't find a free tool which works nicely with ASP.NET MVC and doesn't require much setup.
Google Content Experiments? It's a Javascript-based solution that doesn't require anything from your backend.
You include Google's Javascript on your page
The script randomly substitutes elements on your page as defined by your A/B test
Google's site shows you a nice breakdown of the results...
If you are using the spark view engine, you could probably do it with a variation of the theme filter (http://sparkviewengine.com/documentation/viewlocations#Extendingfilepatternswithdescriptorfilters). For each new visitor to the site, determine if you want them to see the existing or new version of the site and set a cookie. Wire up a descriptor filter that looks for the presence of the cookie and modify the view location to look in the folder containing the modified views. If an alternative view exists, the Spark engine will automatically render it in place of the "normal" view, otherwise it will render the normal view.
If you are using the normal WFVE, then the simplest way to manage this would be to define a folder under Views where your view alternatives live. When you want to provide an alternative view, you place it in a location that matches its position within the normal Views folder but rooted at the alternatives folder e.g. to provide an alternative to Views/Users/login.aspx place your new view at Views/Alternative/Users/login.aspx.
With a convention in place for locating your alternative views, you can extend the WebFormViewEngine and overload CreatePartialView / CreateView to inspect some aspect of the ControllerContext to determine whether to render the default or overloaded view and alter the path as appropriate e.g. changing .../Views/Users/login.aspx to .../Views/Alternative/Users/login.aspx.
I suggest you use Display Modes to achieve A/B testing.
But Display Modes just support simple problems by default.
If you already implement Display Modes in some other scenario. You can consider DisplayModeMatrix (just google it). It helps you use Display Modes more efficiency.
https://www.nuget.org/packages/DisplayModeMatrix/
Wth Display Modes you can simply delete/rename views after A/B testing to clean up your project.
I think there isn't a ready to use solution for this and you will have to improvise.
Try to override your current functionality in well defined points without breaking it. Explicitly draw a border where your regular code and A-B testing code lives.
Inversion of control principle might help a lot here too (i.e. - controller factory could provide derived controller instead of original one). For views&partialviews - you could change viewengine so it would try to look for 'MyPartialViewAB.ascx' instead of 'MyPartialView.ascx'.
And it might be a good idea to take a look what performance counters are (in case you haven't).
As a relative newcomer to both web and MVC, I am looking for a good summary of security best practices that I should implement.
The site will be public facing with "moderately sensitive data" (meaning we can't get sued, but probably wouldn't make many friends if the data got out!) and will have the following security steps taken:
a: Forms/membership authentication and authorization
b: Parameterized queries to prevent sql injection.
c: Automatic timeout with x min of inactivity
c: SSL for client to server encryption
What else do you recommend?
*Securing IIS and the network don't fall under my domain, so I'm more interested in the things I need to do to the software.
If you are using cookies to recognize users, be sure to use an arbitrary token (such as a GUID) to store on the client for identification. I've seen too many websites that store my email address or username in my cookie... just have to change it to another!
Write your software so that it can run under medium trust.
If you are new to web development you should be aware of cross site scripting (XSS). You can use Http.Encode helper method to protect against this in ASP.NET MVC.
Make sure you prevent out of order requests. Ensure client is authenticated before allowing to see sensitive data, or in some cases, make sure the client has come through the correct channel, before allowing a data manipulation. For example, only allow adding an item to your cart if the request came from the product details page. If you don't check, any one can mess around with the action. The URL would be like http://server/cart/add/XYZ123 and anyone could just tweak the 'id' parameter.
Here's another biggie to watch out for: CSRF
http://blog.codeville.net/2008/09/01/prevent-cross-site-request-forgery-csrf-using-aspnet-mvcs-antiforgerytoken-helper/
Take a look at this post by Phil Haack- one of the MS dev’s involved in the development.
Additionally take a look at Microsoft Anti-Cross Site Scripting Library to filter out all incoming parameters
Maybe you should choose methods that can be invoke from outside or not. For example be careful make a method like delete any tables like http://yourhost.com/edit/deletealltable.
Make sure you design your class and methods well. And give attributes [NonAction] for preventing public method being invoke.
Make sure you display data (especially sensitive) as you need with minimum fancy design and use client script as long as needed.
Remove any unused trash files like unused files in your solution folder.
Check and double check and validate any input control like textbox. I just can give something in the textbox to hack your system.
If you use mix between MVC and regular ASP.NET, please remove any dependency between them.
Be sure you cover the basics thoroughly, independently of ASP.NET. Make sure your DBMS has a separate user with the minimal required privileges (e.g., CRUD and executing sprocs from specified databases) set up to access the database from the web application. Parameterizing queries is an excellent idea, but ALWAYS SCRUB YOUR INPUT ANYWAY: it is not a complete defense against sql injection.
Keep your design clean and easy to understand. Document whatever you do clearly, especially on the database side. It would be very bad if all your good work were destroyed by two programmers months or years later--one who didn't realize, say, that the database user for the web application (now accessing a database on a different server) shouldn't have root privileges, and another who added a control that didn't cleanse input properly. There's only so much that can be done about this sort of thing, but designing for the possibility that fools will be maintaining your code isn't so that coders will think you're sweet--it's so that fools won't put you out of business.