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!!
Related
I'm about to build a web application(not web presentation) which will load its content through AJAX (jQuery) into a specific div. There will be a menu above the div and when a user clicks on an item from the menu, the appropriate page will be loaded into the main div.
I'd like to know if there are any cons and pros of choosing this pattern for a web application.
So far I'm avare that the browser back button and history/url will be gone.
Two possible downsides are that it could make it difficult for users to bookmark content on your site and difficult for search engines to differentiate pages on your site.
You should probably provide more information on your reasons for taking this approach. You might have good reasons or it might be a case of using a technology (AJAX) because it is cool to use.
If you want to give the users the impression of fast responsiveness, then yes AJAX load your pages, but still have a different url for each page. This will take more code but it will solve both issues that I mentioned.
http://yourdomain.com/home.aspx //loads its own content via AJAX
http://yourdomain.com/contact.aspx //loads its own content via AJAX
etc
This is really only appropriate if you have a lot of content, or where the content involves time-consuming calculations, such as on a financial site. In most cases, it would be less trouble to just load your pages normally or break you content into paged chunks.
The main con of this approach this will make your site very difficult for search engines to crawl. They don't read Javascript, so your content won't get seen or indexed by them. Try to do progressive enhancement so that they (and any users who don't use Javascript, e.g. screen-readers) don't get left behind.
On the other hand, you can keep browser history functionality. This can be done using the URL hash, e.g. http://www.example.com/#home vs http://www.example.com/#about-us. The nicest way to do this is to get Ben Alman's hashchange plugin and then use the hashchange event:
$(window).hashchange(function(){
var location = window.location.hash;
//do your processing here based on the contents of location
});
This will allow your users to use the history function and the bookmarking function of their browsers. See the documentation on his site for more information.
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.
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
I want to make a site where there user can basically navigate the web from within an iframe. The catch is that I'd like to be able to have more control over what is rendered within the iframe. Specifically,
I'd like to be able to filter out images or text, disable forms etc.
I'd also like to be able to gather feedback such as what links the users clicked on.
Question 1:
Is this even possible using a standard back-end scripting language (like php), with html and javascript on the frontend?
Question 2:
Would I first need to grab the source of the site before it is rendered, then do whatever manipulation is necessary, and finally re-render it somehow?
Question 3:
Could somebody please explain the programming flow that would occur here (assuming its possible)?
I think you would probably want to grab the source of the of site (with server-side code) before rendering it. You might run into cross-site scripting issues if you try to use JavaScript. Your iframe would load a page like render.php and pass the address of the page to render os a querystring parameter. Then use regular expressions to find elements in the HTML that render.php downloads from the address. Rewrite the HTML as necessary and then write it all out to the iframe.
Rewrite links so that that the user is taken to a page you control and redirected onto a target site if you want to track where people are going. Example: a link in the page needs to go to google.com. You would send them to tracker.php?target=http://google.com. You control tracker.php and can log each load of this page and then redirect the user to the target site.
Update:
Another possible solution is to use Apache or other server to proxy the target website. There are modules like mod_proxy for this. There may also be modules that let you parse the HTML or you could roll your own.
I should point out that even the best solutions offered to your question will be somewhat brittle if you do not have full control over the target site. You will want to have lots of error handling or alerting.
You can have a look at this. It uses iFrame really well, and maybe even use the library it has.
I have an ASP.Net application which as desired feature, users would like to be able to take a screenshot. While I know this can be simulated, it would be really great to have a way to take a URL (or the current rendered page), and turn it into an image which can be stored on the server.
Is this crazy? Is there a way to do it? If so, any references?
I can tell you right now that there is no way to do it from inside the browser, nor should there be. Imagine that your page embeds GMail in an iframe. You could then steal a screenshot of the person's GMail inbox!
This could be made safe by having the browser "black out" all iframes and embeds that would violate cross-domain restrictions.
You could certainly write an extension to do this, but be aware of the security considerations outlined above.
Update: You can use a canvas utility function to get a screenshot of a page on the same origin as your code. There's even a lib to allow you to do this: http://experiments.hertzen.com/jsfeedback/
You can find other possible answers here: Using HTML5/Canvas/JavaScript to take screenshots
Browsershots has an XML-RPC interface and available source code (in Python).
I used the free assembly UrlScreenshot.dll which you can download here.
Works nicely!
There is also WebSiteScreenShot but it's not free.
You could try a browser plugin like IE7 Pro for Internet Explorer which allows you to save a screenshot of the current site to a file on disk. I'm sure there is a comparable plugin for FireFox out there as well.
If you want to do something like you described. You need to call an external process that prints the IE output as described here.
Why don't you take another approach?
If you have the need that users can view the same content over again, then it sounds like that is a business requirement for your application, and so you should be building it into your application.
Structure the URL so that when the same user (assuming you have sessions and the application shows different things to different users) visits the same URL, they always see same thing. They can then bookmark the URL locally, or you can even have an application feature that saves it in a user profile.
Part of this would mean making "clean urls", eg, site.com/view/whatever-information-needed-here.
If you are doing time-based data, where it changes as it gets older, there are probably a couple possible approaches.
If your data is not changing on a regular basis, then you could make the "current" page always, eg, site.com/view/2008-10-20 (add hour/minute/second as appropriate).
If it is refreshing, and/or updating more regularly, have the "current" page as site.com/view .. but allow specifying the exact time afterwards. In this case, you'd have to have a "link to this page" type function, which would link to the permanent URL with the full date/time. Look to google maps for inspiration here-- if you scroll across a map, you can always click "link to here" and it will provide a link that includes the GPS coordinates, objects on the map, etc. In that case it's not a very friendly url but it does work quite well. :)