I'm bulding an ASP.NET website just to test my skills, and I'm using lots of callbacks that doesn't require a page refresh, and the URL doesn't change. In this example, assume I'm bulding a web-based Outlook with a treeview, a grid, and a detail pane.
Is there a standard (published or assumed) that says I should postback, or even update my URL from time to time?
The Standard you are probably looking for is called usability. DHTML, Ajax, or whatever you want to call it is fine until it breaks the users expectation of browser behavior. When the back button fails to work, and users can't bookmark the page exactly as they expect, you're doing it wrong.
I don't know about an official standard, but you may want to check out Gmail to see a good example of how something similar was done. The URL changes on the site much more often than the page refreshes.
Related
In a project I'm working on (ASP .Net 3.5 web forms), there is a requirement to restrict the user to work in only 1 window/tab at time. I found this post detailing a solution: http://www.codeproject.com/KB/aspnet/MultipleTabWindows.aspx
However, in one of the pages of my project there is a requirement to open a private (related to the logged in user) pdf document in a new window. The way I'm doing it is by building a request to a page inside of my project and, from that page, stream the pdf document. So, the url of my document looks something like: http://localhost:4087/PdfPage.aspx?type=1&id=2
Q: is there a way to bypass the "single window" rule for only the pdf page or should I say "No, the only way is by opening the pdf in the same window"?
Thanks in advance
When I used the example I put the code on the master page that most of the pages use. Some of the exceptions are links to pdf documents and the login page and assorted error pages.
If that doesn't work you could add logic to the javascript block to look at window.location to allow certain pages through.
Someone needs to say it, implementing any kind of security through javascript is inherently weak. All this really gets you is a short cut to state-management.
Under ideal conditions you should work with your client to make them receptive to the advice their IT department has to offer, instead of them mandating implementation whatever feature they see someone else use. Easier said than done, I know.
Best of luck!!
In my asp.net 2005 app, I would like conceal the app structure from the user. Currently, the end user can learn intimate details of my web app as they navigate and watch the url change. I don't want the end user to know about my application structure. I would like the browser url to not change if possible. Please advise.
thanks
E.A.
URL rewriting is the only one that can provide any kind of real concealment.
Just moving the requests to AJAX or to frames, means anyone (well, more advanced users) can still see those requests being fired, just not in the address bar.
Simplest solution is to use frames - a single frame that holds your application and is 100% * 100%. The URL will not change though the underlying URL can still be seen via "View Frame info", however only advanced users will even figure that out.
In your pages, make sure that they are contained inside the holding frame.
A couple of possibilities.
1) use AJAX to power everything. This will mean that the user never leaves the home page
2) use postbacks to power everything. In this, you'd have all those pages be user controls which you progrmattically hide or show.
3) URL rewriting (especially if this is asp.net 3.0 or later)
My site uses url parameters to dynamically load ascx files into a single main aspx. So if I get 'page_id=123' on the query string, I load the corresponding ascx. The url changes, but only the query string - the domain part remains the same.
If you want the url to remain precisely the same at all times, then frames (per Oded) or ajax (per Stephen) are probably the only ways to do it.
Short answer: use URL encryption
A simple & straight article: http://devcity.net/PrintArticle.aspx?ArticleID=47
and another article: https://web.archive.org/web/20210610035204/http://aspnet.4guysfromrolla.com/articles/083105-1.aspx
HTH
A site has 100's of pages, following a certain sitemap. A user can navigate to page2.aspx from page1.aspx. But if the user goes to page2.aspx directly say through a book marked URL, the user should be redirected to page1.aspx.
Edit: I dont want to go in and add code to every page that needs to fulfill this need.
Note: This is not a cross-page postback scenario.
You might consider something that is based off WorkFlow, such as this: http://blogs.msdn.com/mwinkle/archive/2007/06/07/introducing-the-pageflow-sample.aspx
The WCSF team also included a pageflow application block that you can use as a standalone add-on to your application.
I guess you could check the referrer, and if there isn't one / or it isn't page1.aspx then you could redirect back to page1.aspx.
As another answerer mentioned, you could use the Referrer header, but that can be faked by the client.
Since you don't want to modify each page, you could do something with an IHttpModule. Assuming you have some way of describing the valid page navigations, you could do something like this in the BeginRequest handler:
Check the session for a list of valid pages (using a default list for first visit if none are in the session).
If this request is for an invalid page, redirect to the place the user should be.
Based on this request, set up the list of valid pages and redirect page in the session so it's ready for the next request.
I recently worked with real code that checked to see if referrer was blank and used that as a step in authorization. The idea was users wouldn't be able to fake a referrer, you don't need a custom browser to fake a referrer. Users can book mark your page to delicious, then delicious.com is the referrer (and not blank).
I've had real arguments about how sophisticated a user needs to be to do certain hacks-- i.e. if users don't know how to set the referrer, then you can trust it. While true, it's unlikely your users will write a custom browser, but there already are Firefox addons to set headers, referrers etc and they're easy to use.
Josh has the best answer-- on page2 you should check the page hit log and see if the user has recently visted page1
I like alot of the answers above (specifically the workflow).
Another option, is creating each page as a usercontrol and having page1.aspx control what usercontrol gets loaded. This has the advantage of storing your workflow in a single place instead of on each page.
However, I don't think there's a magic bullet out there. It sounds like this security problem is an afterthought, or possibly reported as a bug, and you have been tasked with fixing it quickly and efficiently.
I would start weighing the answers here with their associated cost in hours.. I suspect the quickest solution will be to check referrer addresses on each page. Although hackable, it is obscure and if that risk is acceptable to you it may be the appropriate solution.
How to login without leaving RP by showing the OP login window in iframe ?
I am using Openid Provider for the login in my Website.
how to implement the login window inside the iframe.
Using an iframe is hugely frowned upon, since the user will be entering their credentials on a page that looks like it is your RP but is supposedly their OP instead. It teaches users to be phished.
If you're going to use an iframe anyway, very little special work has to be done. There are a few approaches you can take though. If you're taking the OpenID Identifier from the user on the page and will display an iframe based on the user input, then the easiest way is probably to use JavaScript when the user clicks "Login" to create an iframe and direct it at http://yoursite.com/redirect.aspx?openid=userSuppliedIdentifier. That page will perform OpenID discovery on the identifier and do the standard redirect to the OP, which will be limited to the iframe since that is where the request came from. The openid.return_to that you send to the OP will have to be to a special page that knows how to "pop out" of the iframe back into your main window. It's really a very similar flow to the popup window approach which I point you to a demo to below, but instead of a popup, you do it in an iframe.
Rather than an iframe, the recommended way if you don't want to send the users away momentarily from your site, is to use a popup window. Just one such example of this is DotNetOpenAuth's ajax login sample, but there are other ways to do it. It's always complicated to get it working across browsers and working securely. We'd need to know what web platform you're using (ASP.NET, PHP, Perl, Python, etc.) before going much further.
(In response to Andrew Arnott's response) I'm bothered that popups are considered the norm for redirects. It's true that Facebook has adopted this approach, but I don't think it's the final solution. From a UI/UX pov in other applications, we've tried to move away from popup windows in favor of inline types of user experience. (popup ads, for instance are extremely annoying) Popups in general are just aggravating. Hence javascript library third-party widgets such as thickbox/lightbox/shadowbox. These solutions allow for iframe loaded content.
Plaxo and Google provided an experiment showing something like a 92% return rate for users who signed in with a two click OpenID process, so the question isn't about return rate, and yes popups can work in that scenario, however...
What I think hasn't been solved is adoption rate, and this comes down to basic usability and user experience, and what most engineers seem to be missing is the fact that users are completely driven off by popups.
It's true that phishing is a problem, but I think the onus and burden for better security lies with the developer on this one, and not the user. For this reason, I still think an inline experience is best, and, unfortunately, iframes are the only methodology currently employable. There are solutions, however, to prevent phishing.
I see that you are discussing usage of iframes for OP authentication. Have you considered the fact that clickjacking becomes possible when using iframes? In fact, many OPs do not allow their pages to be included in an iframe, e.g. VeriSign, Yahoo, myOpenID, etc. They break out of iframes using the HTTP header X-FRAME-OPTIONS, or JavaScript like this:
if (top.location != location) {
top.location = self.location;
}
Take a look at http://ajaxian.com/archives/busting-framebusters-clickjacking-is-still-a-big-issue for more information.
Sometimes Microsoft does something so stunningly dumb that it makes my head hurt. Help me find out it's really not the case ... please!
I've got an issue with the login page of an ASP.NET (3.5) site I'm developing whereby IE (7 or 8 ... can't bear to open 6) doesn't offer to save the password when a user logs in. I've checked other browsers and Firefox, Chrome and Safari all offer to save the password just fine. I've also confirmed that IE password saving on my test boxes is is working OK on other sites and for e.g. Google etc it works fine.
The searching I've done has turned up very little, but what little it did turn up seems to suggest that IE won't offer to save a password if the form on the page contains more than two text controls. That's the case with my form which also has controls to allow a user to register. And when I remove these additional controls, IE magically prompts to save password, so this does seem to be true.
Now ... if ASP.NET would allow me to have multiple forms, all would be well and I would be able to separate out the two functions into standalone forms and IE would prompt to save passwords. But, ASP.NET doesn't allow me to do this as it only allows a single form. I could fudge a non runat=server form in there and try to do this, but guess what? Because my page uses a MasterPage, any form tag I add is automatically stripped out, even if it's a non runat=server form.
So, I don't see any way around this without fundamentally changing what I was trying to achieve. It looks like I have to explain to my users that they won't be prompted to have their passwords saved if they use IE (a Microsoft product) because I developed my site with ASP.NET (err ... a Microsoft product).
If this is so, I just can't get over how head-smackingly ridiculous this is. If anyone can offer any ideas on how to get around it, can tell me I've got it all wrong and am a big, stupid idiot myself, or just wants to confirm that it's not just me that thinks this is monumentously dumb, then please, please do so.
Just for the record, I really don't want to (and don't see why I should have to) compromise my design and split my pages in two (which will result in a worse experience for the user).
#Chris That's what I went for in the end.
So for the benefit of anyone else, I still have my activation controls in a runat=server form and process these in the code for that page. Then I have a second, standard HTML form with HTML input textfields that posts to a different .NET page. This deals with the users login. I pick up the values in this page via Request.Form and deal with the login from here.
Upsides:
It all works and users get their logins remembered as they would expect to.
Downsides:
I lost the ability to use a MasterPage (as I need two forms in the page) so I effectively have had to duplicate the template - I don't like this much.
If the users login is invalid or causes some kind of error, I have to redirect to the initial page and pass it a flag to get it to show a relevant error message - I don't like this much either.
Like I say, though, it just works and in this case that's what was most important. Thanks for your input.