Have a single entry service which is acting like a facade/proxy service for downstream services. The service will need able to detect if the request is a "page request" or "api/xhr" request to perform error handling (302 redirection or 401).
So far have considered:
To use Accept header and detect text/html follow the following reference, can't tell if this is a good indicator to detect a page request
To introduce a custom header for all "api/xhr" request
To enforce all the "api/xhr" requests to follow a "/api" pattern (troublesome as for certain application the xhr is not a restful api)
Any good suggestions are welcome
Ended up using Option 1
Detect page request using Accept header with value "text/html"
As we do not use ajax for partial view
Usually the non-standard HTTP header X-Requested-With is used. Just the presence of the header should be enough. It has at least one advantage over Accept: It cannot be set on a cross-site request, which helps preventing CSRF.
Related
Im currently migrating an old Android application to use Retrofit2
Some of my HTTP calls are DELETEs
While testing I've found my HTTP DELETE calls work fine without Content-Type and Accept headers.
Does HTTP ignore these headers when performing DELETEs?
Is there a Best Practicefor always employing Content-Type & Accept headers?
Accept and Content-Type are used for deciding which representation of a resource should be sent in the response. With a DELETE there generally is no response body, and so there's nothing to decide.
To put it another way, DELETE operates on the entire resource, so there's no purpose in negotiating a specific representation.
I have seen in many places that one of the benefits of token-based authentication over cookie-based authentication is it is better suite for CORS/cross-domain scenario.
But why?
Here is a CORS scenario:
An HTML page served from http://domain-a.com makes an <img> src
request for http://domain-b.com/image.jpg.
Even if there's a token on my machine, how could the mere <img> tag know where to find and send it?
And according to here, it is suggested to store JWT as cookie, so how could that survive the CORS/cross-domain scenario?
ADD 1
Token-based authentication is easier to scale out than session-cookie one. See a related thread here: Stateless web application, an urban legend?
Just for clarification: Requests to any subdomain that you have are also considered as cross origin request (ex. you make request from www.example.com to api.example.com).
A simple <img> GET request to another origin is, indeed, cross origin request as well, but browsers are not using preflighted (OPTION) requests if you use GET, HEAD, POST requests only, and your Content-Type header is one of the followings:
application/x-www-form-urlencoded
multipart/form-data
text/plain
Therefore simple <img> request to another origin won't have problem (regardless if subdomain or totally another domain), as it won't go through preflight, unless it requires credentials, because when you add Authorization header, the request needs to go through preflight.
About storing in localstorage vs in cookie: Localstorage has single origin policy, meaning you cannot access the data you have stored from the subdomain, ie, example.com cannot access data in localstorage of api.example.com. On the other hand, using cookies, you can define which subdomains can access to the cookie. So you can access your token in stored in cookie and send it to server with your requests. Cookies also doesn't allow to access data across different domains.
Hope this helps.
Is there any way to configure Apache to programatically examine a request and cancel the response if the request is invalid. I mean, my intention is to skip responding and just disconnect the client. I'm currently developing a fault-tolerance server fronted by Apache which needs to (stakeholder requirement) ignore answering requests which aren't authorize (I can't even send 401). If I can't use Apache, is there any other way to do it?
Continuation of above comments ...
I dont know how much control you have in JBoss over headers and output sent to the browser, but you can mimic an closed/aborted request like this. From within an application.
Send these Headers, flush and stop all output:
HTTP/1.0 204 No Content
Content-Length: 0
Content-Type: text/html
For example, this is the recommended method the Amazon API suggests as a response to any call that does not want a response.
I am working with Flickr's REST API and it's working fine. By that, I mean I'm making an AJAX call to the Flickr API and getting a JSON object back, parsing the object, etc. etc.
But this raises a question in my mind. If browsers follow the same-origin policy, then how can they make these types of API requests?
This DEMO fiddle is working, but it sends a cross-domain request to the Flickr domain.
How does this cross-domain request work?
The cross-domain request:
$.getJSON("http://api.flickr.com/services/feeds/photos_public.gne?id=" +
id + "&lang=en-us&format=json&jsoncallback=1");
What you need to understand is that, while browsers do enforce the same origin policy (SOP), there are exceptions when SOP is not enforced. For example, if you have an HTML page - you can insert <img> tags that point to images on any domain. Therefore, the SOP doesn't apply here and you are making a cross-origin HTTP GET request for an image.
The demo you linked to works since it uses a mechanism that works in a similar way. The mechanism is called JSONP - http://en.wikipedia.org/wiki/JSONP and I suggest you read the wiki entry and some other blog posts. In essence, JSONP dynamically injects <script> tags to send a request to any domain (the parameters of the request are added as URL query params), since the same origin policy does not apply to <script> tags (as it doesn't apply to <img> tags).
Another way to invoke REST APIs on other domains is to use the cross-origin resource sharing mechanism (CORS) - http://en.wikipedia.org/wiki/Cross-origin_resource_sharing. In essence, this mechanism enables that browsers don't deny cross-origin request, but rather ask the target service if it wants to allow a specific cross-origin request. The target service tells the browser that it wants to allow cross-origin requests by inserting special HTTP headers in responses:
Access-Control-Allow-Origin: http://www.example.com
Consider following scenario:
I have RESTful URL /articles that returns list of articles
user provide his credentials using Authorization HTTP header on each request
articles may vary from user to user based on his privileges
Its possible to use caching proxy, like Squid, for this scenario?
Proxy will see only URL /articles so it may return list of articles only valid for first user that generates the cache. Other users requesting URL /articles can see articles they don't have access to, which is not desirable of course.
Should I roll my own cache or some caching proxy software can be configured to base its cache on Authorization HTTP header?
One possibility to try is using the Vary: Authorization response header to instruct downstream caches to be careful about caching by varying the cached documents based on the request's Authorization header.
You may already be using this header if you use response-compression. The user generally requests a resource with the header Accept-Encoding: gzip, deflate; if the server is configured to support compression, then the response might come with the headers Content-Encoding: gzip and Vary: Accept-Encoding already.
By the HTTP/1.1 RFC section 14.8 (https://www.rfc-editor.org/rfc/rfc2616#section-14.8):
When a shared cache (see section 13.7) receives a request
containing an Authorization field, it MUST NOT return the
corresponding response as a reply to any other request, unless one
of the following specific exceptions holds:
1. If the response includes the "s-maxage" cache-control
directive, the cache MAY use that response in replying to a
subsequent request. But (if the specified maximum age has
passed) a proxy cache MUST first revalidate it with the origin
server, using the request-headers from the new request to allow
the origin server to authenticate the new request. (This is the
defined behavior for s-maxage.) If the response includes "s-
maxage=0", the proxy MUST always revalidate it before re-using
it.
2. If the response includes the "must-revalidate" cache-control
directive, the cache MAY use that response in replying to a
subsequent request. But if the response is stale, all caches
MUST first revalidate it with the origin server, using the
request-headers from the new request to allow the origin server
to authenticate the new request.
3. If the response includes the "public" cache-control directive,
it MAY be returned in reply to any subsequent request.