Can anyone explain the specific difference between using the 'location' and 'refresh' parameters for the redirect() function. Is it ONLY for when Windows misbehaves that you use 'refresh' or does it actually serve a more important purpose?
CodeIgniter's redirect function (located in system/helpers/url_helper.php) allows you to send HTTP headers using PHP's header() function.
The location header instructs a web browser to load a web page and is sent with a 3xx HTTP status code. For example: 301 - moved temporarily or 302 - moved permanently (CodeIgniter's default).
The Location response-header field is used to redirect the recipient
to a location other than the Request-URI for completion of the request
or identification of a new resource.
Refresh is actually a proprietary extension that was created by Netscape. It isn't part of the official standards, but most web browsers have adopted it and support it.
There are several reasons why you might want to use one or the other - location should be supported by all browsers that comply to the standards but refresh may not. refresh could 'break' the back button of the browser (while location won't) and may have performance issues. location sends a reason for the redirect, in a HTTP code, but refresh doesn't; it only instructs the browser to refresh a specified page.
Related
I am implementing OAuth 2.0 protocol within my MVC application. Everything seem to working as expected except for one thing.
How do I handle a scenario with a browser back button when user is been redirected to their application after exchange end point has been completed? Problem is that browser caches state and code parameter and obviously code has already been exchanged.
I can always but some guard code to see if exception is thrown to send user back into original sign in flow that will redirect them to the default pages since there will be already SSO session. Not sure if this is a proper solution.
For information I am using Identity Server and mix of react, angular, mvc applications.
After doing more research I discovered that you can use 303 instead of 302 status code, in that case browsers should not not cache the first redirect per specification.
However based on the note in 302 section, most modern browsers implement 302 as if was 303 redirect and not caching the response.
The solution was, I started adding cache control header with no-cache value to my 302 redirects and browser does not take me back to the previous redirects.
Here is the documentation I took this from: https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
I used 302 instead of 303 because I have multiple redirects and documentation states that in 303 first redirect should not be cached meaning all the other it will ignore.
Is there anyway in JAX-RS, Jersey to ensure a request is Ajax only?
The goal here is to ensure that a number of endpoints are only accessed as AJAX calls and not as a Web URL in a browser?
Reason is the request may contain query parameters that are PHI and we don't want them going into Browser history.
A HTTP request triggered by an AJAX call is not different from any other HTTP request from the POV of the server. Even more, if your web application makes an AJAX request, you can use the tools your browser provides to inspect, copy and manipulate the request. Modern browsers provide the option to copy the exact request as a curl command that can be executed in the shell of your OS. To the server there is not difference between the original made by the browser and the copied request.
There is no way to do what you want to do.
Many (probably the majority) of AJAX calls are done by a browser on a webpage and that webpage has a URL. Is it possible for a webserver to that's receiving the AJAX request to determine the URL of the webpage where the AJAX call was made? I assume there isn't a standard that requires this data in the headers, but perhaps some browsers include that info? Obviously this doesn't apply if the AJAX call was made from a phone app or other application without a URL.
Very generically (though unreliable), check incoming request headers for Referer. That should give you information about the source page.
Just keep in mind it can be spoofed, absent, etc. and shouldn't be considered bullet-proof (though it doesn't sound like you need it to be anyways).
Assume browser default settings, and content is sent without expires headers.
user visits website, browser caches images etc.
user does not close browser, or refresh page.
user continues to surf site normally.
assume the browse doesn't dump the cache for any reason.
The browser will cache images etc as the user surfs, but it's unclear when it will issue a conditional GET request to ask about content freshness (apart from refreshing the page). If this is a browser specific setting, where can I see it's value (for browsers like: safari, IE, FireFox, Chrome).
[edit: yes - I understand that you should always send expires headers. However, this research is aimed at understanding how the browser works with content w/o expires headers.]
From the the HTTP caching spec (section 13.4): Unless specifically constrained by a cache-control (section 14.9) directive, a caching system MAY always store a successful response (see section 13.8) as a cache entry, MAY return it without validation if it is fresh, and MAY return it after successful validation. This means that a user agent is free to do whatever it wants if no cache control header is sent. Most browsers use a combination of user settings and heuristics to determine whether (and how long) to cache in this situation.
HTTP/1.1 defines a selection of caching mechanisms; the expires header is merely one, there is also the cache-control header.
To directly answer your question: for a resource returned with no expires header, you must consider the returned cache-control directives.
HTTP/1.1 defines no caching behaviour for a resource served with no cache-related headers. If a resource is sent with no cache-control or expires headers you must assume the client will make a regular (non-conditional) request the next time the same resources is requested.
Any deviation from this behaviour qualifies the client as being not a fully conformant HTTP client, in which case the question becomes: what behaviour is to be expected from a non-conformant HTTP client? There is no way to answer that.
HTTP caching is complex, to fully understand what a conformant client should do in a given scenario, read and understand the HTTP caching spec.
Unless you send an expires header, most browsers will make a GET request for each subsequent refresh and will either get HTTP 200 OK (it will download the content again) or HTTP 304 Not Modified (and use the data in cache).
Given all the coverage FireSheep has been getting, I have been trying to work out the best practices for balancing HTTP / HTTPS usage for some sites I manage (e.g. blogging sites, magazine sites with user contributed comments).
To me, its over kill to deliver all pages over HTTPS if the user is logged in. If a page is public (e.g. a blog) there is little point encrypting the public page. All I want to do is prevent session hijacking by sniffing cookies over HTTP channels.
So, one plan is:
Login form is over HTTPS
Issue two cookies: One cookie is 'public' and identifies there user for read only aspects (e.g. 'welcome bob!'). The second cookie is private and 'HTTPS only'. This is the cookie that is verified whenever the user makes a change (e.g. adds a comment, deletes a post).
This means that all 'changing' requests must be issued over HTTPS.
We use a lot of AJAX. Indeed, many comment forms use AJAX to post the content.
Obviously, I cant use AJAX directly to post content to a HTTPS backend from a HTTP frontend.
My question is: Can I use script injection (I think this is commonly called 'JSONP'?) to access the API? So in this case there would be a HTTP public page that sends data to the private backend by injecting a script accessed via HTTPS (so that the private cookie is visible in the request).
Can you have HTTPS content inside a HTTP page? I know you get warnings the other way around, but I figure that HTTPS inside HTTP is not a security breach.
Would that work? It seems to work in chrome and FF, but its IE that would be the party pooper!
Another way is to have an iframe which points to a https page that can make all kinds (GET, POST, PUT etc) of Ajax calls to the server over https (same domain as iframe is on https too). Once the response is back inside the iframe, you can post a message back to the main window using HTML5 postMessage API.
Pseudo code:
<iframe src="https://<hostname>/sslProxy">
sslProxy:
MakeAjaxyCall('GET', 'https://<hostname>/endpoint', function (response) {
top.postMessage(response, domain);
});
This works in all modern browsers except IE <= 7 for which you'll have to either resort to JSONP or cross domain communication using Flash.
The problem with JSONP is that you can only use it for GETs.
Can you have HTTPS content inside a
HTTP page? I know you get warnings the
other way around, but I figure that
HTTPS inside HTTP is not a security
breach.breach.
Including HTTPS content inside a regular HTTP page won't raise any alerts in any browser.
However, I don't think JSONP will help you out of this one. Using GETs to post content and modify data is a very bad idea, and prone to other attacks like CSFR