I have a login form on the home page of an ASP.NET 3.5 website which for performance reasons needs to be accessed with a standard HTTP connection. Since the normal postback for an ASP.NET page is relative call for the post, it would mean that when the browser posts the values are sent unprotected.
I would like to do one of two things to make this secure:
Force the Postback to be secure to the same page
Send the post to a different page using an HTTPS connection
Is there a way to implement option one?
I'm also looking at the Authentication Service, but looking at the URL reference it is using a relative path:
Sys.Services._AuthenticationService.DefaultWebServicePath = '../Authentication_JSON_AppService.axd';
I don't see a way to override this to put in an HTTP path.
You could use Cross-Page posting:
http://msdn.microsoft.com/en-us/library/ms178139.aspx
You can change the form's action property with javascript to tell it to submit to a different page with https. I have done this and it works nicely.
You could also change it to submit to the same page with https, but I think asp.net would complain about that (not sure - never tried it).
sample script:
document.forms[0].action = "https://www.whatever.com/submit_page.aspx";
Related
I'm using Webalizer on an intranet, and I want statistics for clicks on outbound links. I set up the links to point to a simple ASP redirection page -
each link resembles "redirect.asp?url=http://outsidesite.com". But Webalizer is not tracking the redirections. Is there a setting in the Webalizer config file that needs to be changed? Or do I need to set up the redirection differently?
I found a solution - I used a META refresh in my ASP page instead of a server-side redirect. The server-side code puts the query string's URL in the refresh's CONTENT value.
Due to cross domain issues, I decided to try a new workaround for detecting sessions between 2 of my domains. I assumed this process would work as I wasn't trying to set any cookies, and it works fine in chrome and firefox, but not in IE9.
I have stepped through in debug mode and the aspx page I request has no access to it's own Request.Cookies, whereas it does when I use chrome.
The process is:
On domain1, (an asp.net mvc application) the user logs in. As part of that login process, a cookie is set on that domain. If I then hit a test page on this server, I can see the cookie has been set.
On domain2 (an asp.net webforms app), I make a jQuery.ajax request to that test page on domain1, which is meant to check for the cookie and return an encrypted string.
When stepping through during this request to domain2 when called via ajax I can see the request.cookies collection is not populated. Frustratingly, User.Identity.IsAuthenticated is true, but I can't get access to the cookie I set.
Is this just another example of the whole cross domain security in action? To me it seems even making the ajax call using jsonp and all the other various hheaders etc, isn't going to help in this situation as it appears to be something more than that?
It seems that you're correct in your assumption. JQuery will by default not send cookies if its connected to a domain that is not the same as the domain the page is on.
You can try using the xhrFields from the JQuery API to perform the cross domain call.
$.ajax({
url: a_cross_domain_url,
xhrFields: {
withCredentials: true
}
});
http://api.jquery.com/jQuery.ajax/
Hope that helps!
is there a way from a asp.net-page code behind with "Request.Redirect()" or another method to redirect to the last page (like Javascript history back)?
You can check the Request.UrlReferrer property, which will be set if the user has navigated to the given page from another one. This is nothing more than the HTTP Referrer header that a browser will set. This will be null if the user navigates to your page directly.
HTTP is stateless, so theres no way of being able to read the browsers history (on the server) in the same way that Javascript can (its client side).
However there are a couple of tricks you can use:
Javascript could write the URL into a textbox which gets submitted to the server
The last URL visited could be stored in session - which can be retreived on a later visit
If using the URL in session method, you'll probably want to code this into a HTTP handler (not module) and this will fire automatically on every request.
Obviously these will only work if the user has previously visited a page, and not directly.
I know that Server.Transfer() should be used to redirect to another ".aspx" page on the same server. But what is the reason behind why should I not use this method to redirect to aspx page on another server or html page?
Your answers are really appriciated.
Firstly, transferring to another page using Server.Transfer conserves server resources. Instead of telling the browser to redirect, it simply changes the "focus" on the Web server and transfers the request. This means you don't get quite as many HTTP requests coming through, which therefore eases the pressure on your Web server and makes your applications run faster.
But watch out: because the "transfer" process can work on only those sites running on the server, you can't use Server.Transfer to send the user to an external site. Only Response.Redirect can do that.
Secondly, Server.Transfer maintains the original URL in the browser. This can really help streamline data entry techniques, although it may make for confusion when debugging.
From : Server.Transfer vs. Response.Redirect
So, in brief: Response.Redirect simply tells the browser to visit another page. Server.Transfer helps reduce server requests, keeps the URL the same and, with a little bug-bashing, allows you to transfer the query string and form variables.
Response.Redirect is more user-friendly, as the site visitor can bookmark the page that they are redirected to.
Transferred pages appear to the client as a different url than they really are. This means that things like relative links / image paths may not work if you transfer to a page from a different directory.
Server.Transfer has an optional parameter to pass the form data to the new page.
Since the release version, this no longer works, because the Viewstate now has more security by default (The EnableViewStateMac defaults to true), so the new page isn’t able to access the form data. You can still access the values of the original page in the new page, by requesting the original handler:
The Server.Transfer() only works within one webapplication.
With Transfer, the "handling" of the request is internally (to the webserver/application) passed on to another page, so the Request object stays the same. This means that the processing needs to stay within the webapplication.
If you want to let processing continue on another webapplication, you will need a fresh Request there. This means that you will need have the browser issue an other request, so you need a Response.Redirect.
Server.Transfer can only happen for single HttpContext. Each virtual directory or app has its own HttpContext object and they know not that they co-exists! so you cannot do that.
Take a look at Server.Transfer Vs. Response.Redirect
Sessions is not shared among servers so that would be a big problem.
I've been using user controls extensively but never use a HttpHandler and was wondering if I am doing something suboptimal or wrong
Unfortunately your question is a little like "Should I use a sandwich or a cement mixer". HttpHandlers and User controls are completely different things.
HttpHandlers are used to process HTTP requests. For example, if you wanted to dynamically create an RSS feed, you could write an HTTP handler that handles all requests for ".rss" files, creates the output and sends it back to the user.
User controls are used within ASPX pages to encapsulate units of functionality that you want to re-use accross many pages.
Chances are, if you're using user controls successfully, you don't want to use HttpHandlers!
Basically a user control is a piece of server logic and UI. An HTTP Handler is only a piece of logic that is executed when a resource on your server is requested. For example you may decide to handle requests for images sent to your server through your own handler and serve images from a database instead of the file system. However, in this case there's no interface that the user sees and when he visits a URL on your server he would get the response you constructed in your own handler. Handlers are usually done for specific extensions and HTTP request types (POST, GET). Here's some more info on MSDN: http://msdn.microsoft.com/en-us/library/ms227675(VS.80).aspx
Expect a better answer (probably before I finish typing this) but as a quick summary.
A user control is something that can be added to a page.
A HttpHandler can be used instead of a page.
Just to clarify the question. I was reading the Hanselman post
http://www.hanselman.com/blog/CompositingTwoImagesIntoOneFromTheASPNETServerSide.aspx
and thinking that I would never solved the problem with a HttpHandler, maybe with a simple page returning a binary content.
This led me to think that I should add HttpHandler to my developer tool belt.
Even an Asp.Net page is an HttpHandler.
public class Page : TemplateControl, IHttpHandler
A user control actually resides within the asp.net aspx page.