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).
Related
I would like some opinions on the following approach to architecting a web application.
A user will navigate to a login page. After logging in, the user will be sent to what I will call a primary page. The idea is to have the primary page contain some common material at the top of the page along with a menu. Below the menu taking up the majority of the page is an IFrame. Each of the menu items, when selected, would load the appropriate page into the IFrame. Here is the main point. The user can navigate through the application using the various menu selections and carry out whatever those selections allow while the primary page remains loaded during the entire session, that is, until the user logs out or closes the browser. This approach does not follow what appears to be the more common paradigm where the browser completely replaces web pages with other web pages as the user navigates through the site. No page stays loaded during the entire session. Is leaving the primary page loaded during the entire session a good idea?
If not, what are the main concerns? Also, can you site any references to a different approach to accomplish the same application-like behavior?
If okay, is there any advantage to using MCV over Web Forms to obtain this behavior?
majority of the page is an IFrame
Iframes are bad. They always have been bad, they always will be. There a dirty hack.
Don't use iframes.
SPA
If you have a good reason not to use actual pages and redirects you can try one of those single page applications that seem to be popular.
I will however remind you that if you rely javascript you basically can't do SEO.
Progressive enhancement
As an aside read up on Progressive Enhancement. You should be doing that.
Partial views
If you like having a large portion of your website static then you can always load partial views over ajax and render them on the client.
Of course because your doing progressive enhancement your doing full page redirects and loads aswell. The partial view rendering on the client is just bells and whistles.
.NET
As for using C# frameworks I would personally recommend Nancy.
If you want to use ASP (god knows why) I guess you can use ASP.NET MVC, sure it's far from optimum but at least it's not ASP.NET webforms
I don't think it's the absolute evil, but your solution does not actually follow the "normal" behaviour of an HTML site, and browsing may be less intuitive.
Users will have problems for bookmarks or using back button, for example.
You will not be able to adapt the menu accoring to the current displayed content (or will have a hell of synchro problems!), for example showing wich section you are in.
The common solution for web is to use a layout, or two-step view pattern (see http://framework.zend.com/manual/en/zend.layout.introduction.html)
I don't know well webforms, but MVC is known as the standard de facto for most web applications and frameworks. It's nice because of the splitting of the roles and the organization it enforces.
so I just migrated a bunch of my old web sites to .net mvc and turned them loose on the net last week.
I optimized them as best I know how for SEO but I'm noticing that NONE (not a single one!) of my sub pages is being displayed on google...only my home pages.
I created controllers for the products to try and give them plugs for each page.
ex:
http://www.mywidgets.com/widget_to_make_coffee/coffee_making_widgets
ironically, google is still showing some of my sub-pages from the old site, which I have redirecting to the new, but I fear that when it fully updates its index, I will lose that placement and not gain the placement from my new stuff as it's no-where to be found...
is this bad practice? Should I have structured everything off of the home controller?
Should I have structured everything off of the home controller?
No. Something else it's going on.
One of the advantages of ASP.NET MVC is that you can de-couple your routes (URLs) from the logic of your code (models/views/controllers)
The only important thing is that you have something at the old urls passing a 301 redirect to the new urls. Google will fix itself pretty quickly after that.
Depending on how many incoming links you've got, you might end up keeping the redirector up permanently.
I'm pretty new to ASP.NET MVC and I just want ask of this scenario is possible and, if so, could anybody provide any resource links on how to implement it.
Say I have a site that can be accessed from www.mysite.com, can I also have the same site load up through www.mysite2com, www.mysite3.com and so on? effectively providing the ability to run multiple sites from a single code base?
The idea is to have the site content and style sheet change depending on site visited but keep the structure the same.
thank you very much for any help you can provide :)
Kris
Yes, this is possible
http://web.archive.org/web/20100119084358/http://just3ws.wordpress.com/2010/01/03/skinning-your-asp-net-mvc-application-based-on-your-sub-domain
This example uses subdomains of the same domain but nothing stops you from using the same logic and have different images/CSS/paths etc generated based on full HOST/domain name
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.
Its time to rebuild my portfolio site, and I am thinking of either using Silverlight (still have to learn the basics but would be fun) or use MVC.NET.
I would like to use Silverlight since its something I am really interested in learning, and building up a small portfolio site should not be an out of this world task. However I do not know if its advisable, since I want my portfolio to be viewed and accessed by everyone, platform independent.
What do you guys think?
Thanks
From an SEO and ease of page bookmarking point of view you might want to go with traditional HTML, i.e. ASP.NET MVC.
The downside of building an entire site in Flash or Silverlight is that users can't bookmark a specific page within it, and search engine bots can't by default follow links or parse the text.
The following page deals with SEO and Silverlight sites.
http://silverlight.net/learn/whitepapers/seo-for-silverlight/
If really want platform independence you should avoid Silverlight, users on Linux especially won't get a good experience at the moment.
However if you want reasonable access by people in general then Silverlight is do-able.
You might ask yourself whether coupling your important portfolio site with your own personal improvement plan is a good idea.
Utlimately then develop your site with ASP.NET-MVC then spend some time with Silverlight without impacting your site, or perhaps include some content via Silverlight.
You can build both of them. It will allow you to see the differences between them and compare them.
I think your portfolio site should show your works also with its structure. If you are doing design, It would be nicer to make your site with Silverlight!
Those are actually not two techonologies that are related in any way or say that you should use one over another. You can have a ASP.NET MVC site (which I prefer and suggest to you) and then use Silverlight parts in it.
I prefer using Silverlight (or Flash for the same matter) only for animations, maybe parts of a website but not for entire website. If only portfolio will be built in Silverlight you should definitely do it in classic HTML too for users that lack Silverlight support.
May be it's too late about answering.
Now, Silverlight seems to go to its end. Microsoft wants to stop supporting it after 2021.
But, since Microsoft says they will ever support OOB mode, I think you could continue to developp to Silverlight today.
So I think, it's up not for animations. It's up to users of the application :
Silverlight has some good avaibilities to simulate windows like application.
After loading data in cache, you can have better user reactivity.
And, you get an other good point : user can easily cancel data they write.
At the end, with RIA services technology, for developpers, this is pretty easy to simulate entities like in client development.
As it says before, you can have mvc web application with silverlight inside.