I wish to test the URL at the end of a series of redirects. With Automatically follow redirects on, this appears not to be possible.
I have a number of redirects when my Postman request is made and I would like them to be executed automatically, so I am not turning off Automatically follow redirects, but my test needs to check the final URL of the request:
pm.test("URL contains final addr", function () {
pm.expect(pm.response.url).to.include("/Customer.aspx");
});
This question is very similar to this post however I need to still get the URL with redirection turned on.
How should I be retrieving the true, final URL after a number of redirects?
Related
I have a url, /users/sign_out, that is supposed log out a user and redirect them to my root url, /. I want to handle this fetch through my service worker, because I want to clean some items out of the cache before sending the user back to root. However, since the client doesn't see the redirect that happens on the fetch from the service worker, the user winds up on my splash screen but sees the pre-redirect address /users/sign_out.
Is there any way currently that I can handle the fetch and also allow the client to see the correct final url?
It appears that eventually there will be a Response.redirect() method that will allow updating a response with the final url. It looks like there is also likely to be some kind of finalURL option that would also address this case. But is there anything that I can use now? On Twitter, Jake Archibald (#jaffathecake) said I could construct a new Response myself - and I can, but even after looking at the spec and the MDN docs a bit, I still can't figure out how to specify the correct url for it.
If there is in fact a way to construct a Response object that does what I need, could someone show me how that works?
There's an example at https://github.com/GoogleChrome/samples/tree/gh-pages/service-worker/mock-responses showing how you could create a Response object and use it to respond to a fetch event.
In that case, we're creating a 200 OK response with a body, but there's nothing stopping you from creating an arbitrary response. You'd probably want a 302 Found for your use case, so you'd do something like:
var responseInit = {
status: 302,
statusText: 'Found',
headers: {
Location: '/' // Or whatever URL you want to redirect to.
}
};
var redirectResponse = new Response('', responseInit);
event.respondWith(redirectResponse);
You can include code that clears your caches inside the fetch handler before you respond to the event, and you'd obviously want to check the event.request.url value first to make sure you only respond to requests for /users/sign_out with your custom response.
I am working on an application with ASP.NET MVC Routing + AngularJS routing.
My URL lookslike:
https://example.com/Request/#/Search/Request/123
when I breakdown this (http://example.com/Request) is handled by ASP.NET MVC routing. i.e. (Area = Request, controller = "Default", action = "Index")
(#/Search/Request/123) is handled by AngularJS routing.
This works perfectly when I am on http://localhost:8080/
The issue is when I deploy this application to https://example.com/
In this case, If user clicks on above link (received via email),IE 9 recognizes only (https://example.com/Request/") and the server never gets (#/Search/Request/123).
We have enterprise SSO implemented on web server. SSO client intercepts http request and uses URL to redirect back to requested page after authentication.
if # fragment is not sent as part of http request url, sso is not able to redirect back to same page.
I believe this to be a common scenario/issue. I would keep changing the URL scheme as last resort. e.g. (# to !).
How to solve this?
Just found a blog that dealt with this issue exactly:
http://codetunnel.io/how-to-persist-url-hash-fragments-across-a-login-redirect/
He offers two ideas:
When the page loads there simply needs to be some JavaScript that accesses the hash fragment and appends it to the redirect URL in the hidden field. Here's an example using JQuery for simplicity
$(function () {
var $redirect = $('[name="redirect"]');
$redirect.val($redirect.val() + window.location.hash);
});
Or, alternatively
Instead of appending the hash fragment to the hidden field value, you could avoid sending it to the server at all and simply append it to the form action URL.
$(function () {
var $loginForm = $('#loginForm');
var actionUrl = $loginForm.attr('action');
$loginForm.attr('action', actionUrl + window.location.hash);
});
Fragments (the part of the URL after the #) are not necessarily sent to the server-side by the browser. They are for client-side usage only (navigating to a specific location in the document, JavaScript support).
RFC 2396 section 4.1:
When a URI reference is used to perform a retrieval action on the
identified resource, the optional fragment identifier, separated from
the URI by a crosshatch ("#") character, consists of additional
reference information to be interpreted by the user agent after the
retrieval action has been successfully completed. As such, it is not
part of a URI, but is often used in conjunction with a URI.
(emphasis added)
Therefore, the URL scheme you came up with will not work reliably unless you change the # to another character. Alternatively, you could use JavaScript to transfer the information from the fragment in an input that will be reliably passed back to the server. But do note that solution will only work if JavaScript is enabled in the browser, so it is (also) not a 100% reliable solution that will work with all clients.
Either way, using a URL without a fragment is a more reliable approach and IMO a better design choice if you expect that part to be interpreted by the server.
I would remove ugly URL's from your application all together.
This article will walk you through removing ugly URL's in a asp.net-mvc project. It will also ensure that you have your RouteConfig.cs setup correctly.
http://www.codeproject.com/Articles/806500/Getting-started-with-AngularJS-and-ASP-NET-MVC-P
I'm trying to set up Bitbucket OAuth for my site but for some reason Bitbucket is not properly redirecting back to my site. I've created an OAuth key and secret and I'm using the Guzzle OAuth plugin in my Silex application.
First I request a temporary token via the oauth/request_token endpoint. Using that token I redirect to oauth/authenticate endpoint:
$app->get(
'/auth/bitbucket',
function () use ($app) {
$client = new Client('https://bitbucket.org/api/1.0');
$oauth = new OauthPlugin(
array(
'consumer_key' => $app['bitbucket.key'],
'consumer_secret' => $app['bitbucket.secret'],
'signature_method' => 'HMAC-SHA1',
'callback' => urlencode('http://mysite.local/auth/bitbucket/callback')
)
);
$client->addSubscriber($oauth);
$response = $client->post('oauth/request_token')->send();
parse_str($response->getBody(), $result);
return $app->redirect(sprintf('https://bitbucket.org/api/1.0/oauth/authenticate?oauth_token=%s', $result['oauth_token']));
}
);
This will bring up the page on the Bitbucket site where the user can grant or deny access to their account. After I click "Grant access" Bitbucket should redirect back to the callback url that was specified earlier but instead it will append my callback url to the Bitbucket url like this:
https://bitbucket.org/api/1.0/oauth/http%3A%2F%2Fmysite.local%2Fauth%2Fbitbucket%2Fcallback?oauth_verifier=xxxxxxxxxx&oauth_token=xxxxxxxxxxxxxxxxxx
This obviously results in a Bitbucket 404 page. Does anyone have an idea why the redirect to my callback url is not working properly?
According to documentation, when requesting token from bitbucket's API, you MUST have those parameters when sending POST request to https://bitbucket.org/api/1.0/oauth/request_token:
oauth_consumer_key
oauth_nonce
oauth_signature
oauth_signature_method
oauth_timestamp
oauth_callback
Also, don't urlencode your callback URL. Replace this:
'callback' => urlencode('http://mysite.local/auth/bitbucket/callback')
With this:
'callback' => 'http://mysite.local/auth/bitbucket/callback'
When you are sending POST request, you do not need to encode any of parameters.
Indeed, as you mentioned in comment, documentation does show encoded parameters in example, as in:
https://bitbucket.org/api/1.0/oauth/request_token?oauth_version=1.0&oauth_nonce=7f2325b3c36bd49afa0a33044d7c6930&oauth_timestamp=1366243208&oauth_consumer_key=HUpRcDUduZrepL6sYJ&oauth_callback=http%3A%2F%2Flocal%3Fdump&oauth_signature_method=HMAC-SHA1&oauth_signature=qZyTwVA48RzmtCHvN9mYWmlmSVU%3D
Issue you have is not wrong documentation, but misunderstanding of POST method. Also check Wikipedia page. Unlike GET where parameters are passed in URL, POST request method stores it's data in body. That allows us to send any data type, arbitrarily long.
Data that is passed in body of request is automatically encoded as in this example (copied from Wikipedia page):
Name=Jonathan+Doe&Age=23&Formula=a+%2B+b+%3D%3D+13%25%21
Looks similar to GET method when you encode data manually, right? However, if you urlencode data in POST request you actually end up with double encoded data, which is cause of problems in your case.
I really think that some basic knowledge of HTTP methods and Internet protocols is required before playing with any API.
Also, check some HTTP traffic monitor (debugger), like free Fiddler. It will allow you to see all HTTP data that is sent from your browser, essentially enabling you to learn by own examples.
I'm not sure how your framework works, but the callback parameter may be url encoded by the framework before the request is made. Since you also url encode it, your url is url encoded twice. Bitbucket will decode it once, leaving it with a url encoded url, which won't have the scheme set (http in this case), and your browser won't know it is an absolute URL, and will thus navigate to somewhere inside Bitbucket (as you observe). Try removing the extra url encode and see if that helps.
I was sending request to Live Oauth and gotten them call back to return url successfully.
However, when I want to read the parameter at this return url, I am jammed...
The url come with #
$_GET simply can't get anything beyond #
http://www.abc.com/oauthlive/testing.php#access_token=theaccesstokenstring&token_type=bearer&expires_in=3600&scope=wl.basic
What shall I do.
our front end guy needs to form a url containing the hash, (i.e, http://blah/#some-link.) when we hit this on the browser and inspect the http traffic using fiddler, we saw that everything after blah/ gets removed, so the request is really just http://blah/. we also confirmed this on our server eclipse debug log.
the request gets redirected to the correct login page by Spring security(because user hasn't logged in), but the url on the browser now shows:
http://blah/some-link (the hash got removed) but the url on the browser should really be http://blah/log-in.
any idea why this is? any fix or workaround? thanks in advance.
URI part after # is called a fragment:
URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
Scheme and hier-part identify the location of a document, and fragment helps the browser to identify a location inside this document.
Fragment is stripped from URI by client software before it is sent as a part of request.
From RFC3986:
the fragment identifier is not used in the scheme-specific
processing of a URI; instead, the fragment identifier is separated
from the rest of the URI prior to a dereference, and thus the
identifying information within the fragment itself is dereferenced
solely by the user agent, regardless of the URI scheme. Although
this separate handling is often perceived to be a loss of
information, particularly for accurate redirection of references as
resources move over time, it also serves to prevent information
providers from denying reference authors the right to refer to
information within a resource selectively.
Content after the # is only used on the client side, per HTTP specification. If you require that information on the server, you can either use a different separator, or you can submit it via ajax after the page has loaded by reading it on the client with javascript.
The part of the URI including and after the hash (#) is never sent to the server as part of the HTTP request.
The reason is that the hash identifier was originally designed to point at references within the given web page and not to new resources on the server.
If you want to get the hash identifier, you'll have to use some client-side JavaScript to grab the value and submit it with the form.
Hashmark is removed from URL when the back button is clicked in IE9, IE10 or IE11
In IE10 , first time on clicking the HREF link leads to the correct below url:
http://www.example.com/yy/zz/ff/paul.html#20007_14
If back button is clicked again the, then it comes to the below url:
http://www.example.com/yy/zz/ff/paul.html
Solution :
Please change the url with https
It works for me
you can do this with javascript
<script>
if(window.location.hash) {
console.log(window.location.hash);
window.location.hash = window.location.hash;
}
</script>