We have two virtual URL's that is using webseal for our intranet appication such as,
https://third-party-site.com/myapplication/Default.aspx
https://my-application.com/Default.aspx
which internally points to https://original-url.com:8080/Default.aspx after successful authentication from their respective sites.
I want to get the current URL from Default.aspx page. I have tried with Request.Url but it is returning the original URL. ie. https://original-url.com:8080/Default.aspx
For eg. if I access Default page from https://third-party-site.com/myapplication/ then it should return the current URL as https://third-party-site.com/myapplication/Default.aspx.
Currently it is returning as https://original-url.com:8080/Default.aspx
Is there any way to get the virtual URL itself?
Request.Url returns https://original-url.com:8080/Default.aspx because this is what IIS receives.
You don't describe your infrastructure but I believe you have load balancer or some kind of rouer before the IIS. It is often (de facto a standard) that those services inject http header called X-Forwarded-For. You can try get that by:
if (Request.Headers["X-Forwarded-For"].Count > 0) { ... // use the real domain }
If that fails you should check documentation of your service handling the requests before the IIS.
Related
Hey all I am trying to find some code that will allow me to know what domain the POST request to the web service is coming from.
As an example:
If the web service is on domain:
bob.com/webService/Postsomething
And the client loads a page up on domain:
bill.com/postpage.html
Once the web service is clicked off using AJAX on the html page I want to be able to get the following information from the post function its calling:
bill.com
So far I have only been able to get the IP and host name of where the web service is on and not the client domain they are asking for information from the web service from.
You could use the referrer HTTP header:
public HttpResponseMessage Get()
{
var domain = Request.Headers.Referrer?.GetLeftPart(UriPartial.Authority);
...
}
Of course this header is not guaranteed to be present and you absolutely cannot rely on it because the client making the HTTP request could simply decide not to send it. You should always check if it is null before using it.
We use Request.Url.GetLeftPart(UriPartial.Authority) to get the domain part of the site. This served our requirement on http.
We recently change site to https (about 3 days ago) but this still returns with http://..
Urls were all changed to https and show in browser address bar.
Any idea why this happens?
The following example works fine and returns a string with "https":
var uri = new Uri("https://www.google.com/?q=102njgn24gk24ng2k");
var authority = uri.GetLeftPart(UriPartial.Authority);
// authority => "https://www.google.com"
You either have an issue with the HttpContext class right here, or all your requests are still using http:
You can check the requests HttpContext.Current.Request.IsSecureConnection property. If it is true, and the GetLeftPart method still returns http for you, I think you won't get around a replacing here.
If all your requests are really coming with http, you might enforce a secure connection in IIS.
You should also inspect the incoming URL and log it somewhere for debugging purposes.
This can also happen when dealing with a load balancer. In one situation I worked on, any https requests were converted into http by the load balancer. It still says https in the browser address bar, but internally it's a http request, so the server-side call you are making to GetLeftPart() returns http.
If your request is coming from ARR with SSL Offloading,
Request.Url.GetLeftPart(UriPartial.Authority) just get http
I created REST base webAPI in MVC 4 and hosted on server when I call this from HTML on other domain and on my local pc I need to call it as JSONP request like put callback=? in url so it can be jsonp. My question is that why this is so? if its due to cross domain then how google and facbook and other companies host their api we also call it from our own domain but we dont keep callback=? in their url.
so why my API need callback=? in url if i call it from other domain or on my local pc with simple jquery html.
Its because of the Same Origin Policy imposed by the browsers.
See
http://www.w3.org/Security/wiki/Same_Origin_Policy
http://en.wikipedia.org/wiki/Same_origin_policy
.
Also note that CORS might be a better option than JSONP in the future
http://en.wikipedia.org/wiki/Cross-origin_resource_sharing
EDIT: ------------
If you have gone through above links you would see that JSONP allows users to work-around this Same Origin Policy security measure imposed by the browsers.
Trick is browsers allow tags to refer files in other domains than the origin.
Basically what happens is with JSONP, you send a callback function name to the server appended to the query string. Then the server will pad or prefix it's otherwise JSON request with a call to this function, hence the P in the name to denote response is padded or prefixed.
For example you can create a script tag like
then the target server, should send a response such that
mymethod({normal: 'json response'})
when this repsone is evaluated on the client side (as for any other javascript file) it will effectively call your method with the JSON response from that server.
However, this can only do GET requests.
If you want to make POST (PUT/DELETE) requests you need to use CORS in which server needs to set a specific header beforehand.
Access-Control-Allow-Origin: www.ext.site.com
Hope this helps.
Because of the same-origin policy limitations. The same-origin policy prevents a script loaded from one domain from getting or manipulating properties of a document from another domain. That is, the domain of the requested URL must be the same as the domain of the current Web page. This basically means that the browser isolates content from different origins to guard them against manipulation.
I am using Microsoft.Web.WebPages.OAuth. I was able to register Google, Facebook, Twitter, Stack Exchange, MyOpenID...
Now I am trying to add Microsoft Live, so I registered:
OAuthWebSecurity.RegisterMicrosoftClient("applicationID", "key");
and called
OAuthWebSecurity.RequestAuthentication("microsoft", Url.Action("Authorization", new { returnUrl = "/" }));
To this point everything is working fine, I get redirected to the login page. The problem is when I come back to
OAuthWebSecurity.VerifyAuthentication();
It says:
The remote server returned an error: (400) Bad Request.
What do I have to do?
I had the same problem. After a lot of research, I came across this bit of source code with the comment:
// Only OAuth2 requires the return url value for the verify authenticaiton step
This means that when you call VerifyAuthentication, you must use the overload that passes the return url for validation by the oauth2 provider (the Microsoft Live ID provider in this case).
Sure enough, when I dig through the walkthrough on the asp.net website, I find that they are indeed passing back the return url, as the url from the action of the callback.
So instead of:
OAuthWebSecurity.VerifyAuthentication();
You need:
var returnUrl = Url.Action("Authorization", new { returnUrl = "/" })
OAuthWebSecurity.VerifyAuthentication(returnUrl);
The return url should match exactly the same as you specified earlier in the RequestAuthentication method.
What is the Redirect Domain that you are using? I found (when doing this) that, since I had specified my actual domain name, I needed to have the domain name point to the local site.
To work around, I added an entry to the hosts file to point my domain at 127.0.0.1 (i.e. because I was debugging and running locally).
I created a simple page using the code provided by this page (the first sample):
http://www.dotnetopenauth.net/developers/code-snippets/programmatic-openid-relying-party/
But I can't seem to get it to work, I can redirect to the provider but when the provider redirects back to my page, I get error 500, "The request was rejected by the HTTP filter".
I already checked ISAPI filters which I have none.
I've never seen that error before. Is this page hosted by the Visual Studio Personal Web Server (Casini) or IIS? I suspect you have an HTTP filter installed in IIS (or perhaps your web.config file) that is rejecting the incoming message for some reason.
Note that you need to turn off ASP.NET's default page request validation on any page that can receive an OpenID authentication response because those responses can include character sequences that look like HTML/Javascript-injection attacks but in fact is harmless.
I discovered that I'm using Isa in the server, so I just followed this instructions to get it working.
http://blog.brianfarnhill.com/2009/02/19/sharepoint-gets-the-error-the-request-was-rejected-by-the-http-filter/