I'm looking for the equivalent of this javascript
window.location.origin
but server side, while building mvc pages.
For example, if you are here
http://website.com/123,
it would return
http://website.com
Its important that i have the "http://" part
I'm a fan of
string url = Request.Url.PathAndQuery.length > 1
? Request.Url.AbsoluteUri.Replace(Request.Url.PathAndQuery, string.Empty)
: url;
Keeps your Http/Https, Port (if applicable), and HostName/IP.
DotNetFiddle Examples
Updated to Account for PathAndQuery length of 1.
you could try
#String.Format("{0}://{1}", Request.Url.Scheme, Request.Url.Authority)
Or
#String.Format("{0}://{1}", Request.Url.Scheme, Request.Url.Host)
Authority will include the port number
I think you looking for Request.Url or RawUrl.
Uri.Scheme of Request.Url will give you info on http/https difference.
The window.location.origin in javascript returns the protocol, port (if any), domain and extension of the current url.
If you want to get the same information from an URL, the accepted answers will provide that to you.
If you want the same behavior, ie a piece of javascript is calling your server method and you want to know where it is calling from, you can inspect the HttpRequest.URLReferrer. However this can be spoofed easily and thus is not reliable.
Related
In my Apigee API Proxy, I need to get the environment URL that is defined in my configuration, so that I can send it as part of the response.
For example: http://myorg-test.apigee.net/pricing
However, when I try to get it using proxy.url, I get an aliased path, like http://rrt18apigee.us-ea.4.apigee.com/pricing
Currently, I'm trying to get it like:
var response = {
proxyUrl : context.getVariable("proxy.url"),
};
Here is a work around. You can try to get the following variables and create the entire URL
Get the request scheme (http or https) from request.Headers.X-Forwarded-Proto (if you are using cloud version) or client.scheme if you are using on-prem
Get the host name from request.host
Get the entire request path from request.path
Entire list of URL query params and list from message.querystring
You can then construct the entire request URL.
( I know this should not be this painful. Please log a bug in case proxy.url is really broken. )
My site at www.kruaklaibaan.com (yes I know it's hideous) currently has 3.7 million likes but while working to build a proper site that doesn't use some flowery phpBB monstrosity I noticed that all those likes are registered against an invalid URL that doesn't actually link back to my site's URL at all. Instead the likes have all been registered against a URL-encoded version:
www.kruaklaibaan.com%2Fviewtopic.php%3Ff%3D42%26t%3D370
This is obviously incorrect. Since I already have so many likes I was hoping to either get those likes updated to the correct URL or get them to just point to the base url of www.kruaklaibaan.com
The correct url they SHOULD have been registered against is (not url-encoded):
www.kruaklaibaan.com/viewtopic.php?f=42&t=370
Is there someone at Facebook I can discuss this with? 3.7m likes is a little too many to start over with without a lot of heartache. It took 2 years to build those up.
Short of getting someone at Facebook to update the URL, the only option within your control that I could think of that would work is to create a custom 404 error page. I have tested such a page with your URL and the following works.
First you need to set the Apache directive for ErrorDocument (or equivalent in another server).
ErrorDocument 404 /path/to/404.php
This will cause any 404 pages to hit the script, which in turn will do the necessary check and redirect if appropriate.
I tested the following script and it works perfectly.
<?php
if ( $_SERVER['REQUEST_URI'] == '/%2Fviewtopic.php%3Ff%3D42%26t%3D370' ) {
Header("HTTP/1.1 301 Moved Permanently");
Header("Location: /viewtopic.php?f=42&t=370");
exit();
} else {
header('HTTP/1.0 404 Not Found');
}
?><html><body>
<h1>HTTP 404 Not Found</h1>
<?php echo $_SERVER['REQUEST_URI']; ?>
</body></html>
This is a semi-dirty way of achieving this, however I tried several variations in Apache2.2 using mod_alias's Redirect and mod_rewrite's RewriteRule, neither of which I have been able to get working with a URL containing percent encoded chars. I suspect that with nginx you may have better success at a more graceful way to handle this in the server.
I am trying to get access token using from facebook graph API in my rails 2.3 based web application. The request I am sending for that is :
https://graph.facebook.com/oauth/access_token?client_id=<client_id>
&redirect_uri=http://localhost:3001/facebook_callback
&client_secret=<client_secret>
&code=AQBgog2NvoUYQCXsa2bGpj--s9RD71F3zTKX344cUZ-
AWX4CNhdx3Yerl_wmzQkQ4zIUFVS_CRoN0zXaEW63dHcC9sH6_
vl7ljSxwA6TLSrkWVcfdfdrmwBTlMNIzyJr0h6irGW1LCdTw8
Racgd8MQ9RgVn1gFL26epWA
And it is redirecting me to
http://localhost/facebook_callback?code=AQBgog2NvoUYQCXsa2bGpj--
s9RD71F3zTKX344cUZ AWX4CNhdx3Yerl_wmzQkQ4zIUFVS_CRoN0mAB_Sr1H4K
dXIlzXaEW63dHcC9sH6_vl7ljSxwA6TLSrkWVcfdfdrmwBTlMNIzyJr0h6irG
SxsrRAXtdviNsBTMW1LCdTw8Racgd8MQ9RgVn1gFL26epWA
I am getting error in both development and production environment . I am not able to get the access token. Has anyone else face the problem ??
This looks correct - Facebook redirects to your redirect url with the code= parameter. You then need to exchange the code for an access token. See here: http://developers.facebook.com/docs/authentication/
edit: my bad, I misread the first section. You can sometimes have problems using localhost as a redirect. Are you using a live domain without port in your non-test environment?
Well, I found solution of my problem :
The problem was with the path which I was using for request of access_token . I placed a slash in front of the path and bingo. It worked like a charm.
So instead of
oauth/access_token?client_id=#{ #client_id }&redirect_uri=#{ #redirect_uri }&client_secret=#{ #client_secret }&code=#{ code }"
we just need to use
/oauth/access_token?client_id=#{ #client_id }&redirect_uri=#{ #redirect_uri }&client_secret=#{ #client_secret }&code=#{ code }".
Thanks to all people for your efforts.
I have a DAV protocol that stores out-of-band data in the url anchor, e.g. the ghi in DELETE /abc.def#ghi. The server is a Flask application.
I can see the request come in on the wire via tcpdump, but when I look at the werkzeug Request object (such as url() or base_url()), all I get back is /abc.def. The #ghi has been stripped out.
Is there a method that returns this information, or do I have to subclass Request to handle this myself? If so, is there an example I can use as an inspiration?
I ran into the same problem. Facebook authentication API returns the access token behind a hash appended into the redirection url. In the same way, Flask's request.url drops everything in the URL behind the hash sign.
I'm also using Flask so I think you can use my brute-force workaround using Javascript's window.location.href to get the full URL. Then, I just extracted the piece that I needed (the access token), put it into a redirection URL where I can pass the access token as an argument to the receiving view function. Here's the code:
#app.route('/app_response/<response>', methods=['GET'])
def app_response_code(response):
return ''' <script type="text/javascript">
var token = window.location.href.split("access_token=")[1];
window.location = "/app_response_token/" + token;
</script> '''
#app.route('/app_response_token/<token>/', methods=['GET'])
def app_response_token(token):
return token
In case you manage(d) to do this within Werkzeug, I'm interested to know how.
From Wikipedia (Fragment Identifier) (don't have the time to find it in the RFC):
The fragment identifier functions differently than the rest of the URI: namely, its processing is exclusively client-side with no participation from the server
So Flask - or any other framework - doesn't have access to #ghi.
You can do this using flask.url_for with the _anchor keyword argument:
url_for('abc.def', _anchor='ghi')
Is there a length limit for the fragment part of an URL (also known as the hash)?
The hash is client side only, so the rules for HTTP may not apply to it.
It depends on the browser.
I found that in safari, chrome, and Firefox, an URL with a long hash is legal, but if it is a param send to the server, the browser will display an 414 or 413 error.
for example:
an URL like http://www.stackoverflow.com/?abc#{hash value with 100 thousand characters} will be ok. and you can use location.hash to get the hash value in javascript but an URL like http://www.stackoverflow.com/?abc&{query with 100 thousand characters} will be illegal, if you paste this link in the address bar, a 413 error code will be given and the message is the client issued a request that was too long. If that is a link in a web page, in my computer, Nginx response the 414 error message.
I don't know the situation in IE.
So I think, the limitation of the length of URL is just for transmission or HTTP server, the browser will check it sometimes, but not every time, and it will always be allowed to be used as a hash.
There is definitely a length for the whole url.
Read
RFC2616 - Hypertext Transfer Protocol
Maximum URL length is 2,083 characters in Internet Explorer