There is no doubt that the HTTPCookie is indeed inside the HTTPCookieStorage, but I wonder if there is any way to confirm that it's being sent from programmatic standpoint?
Of course intercepting HTTP traffic via sniffers doesn't count.
There is no way to check that programmatically - the notion of HTTPCookieStorage being configured on the URLSessionConfiguration leads to it completely obscuring the Cookie-related details from the programmer. It operates like magic way out of scope of your vision.
To be honest, I couldn't even tell you that happens if you set Cookie header manually via allHTTPHeaderFields but if there were already cookies for this very same domain and path in the HTTPCookieStorage - like, do they get merged, or does your custom header get discarded...
Related
To provide some custom caching via a webextension, I use web_accessible_resources and redirect accesses towards them in a background script – see my previous question for details.
While that works content wise, I cannot find a way to change the response headers of the cached content, for example the Last-Modified header. So when I cache content that the original website does some consistence checks on, this will fail.
I tried to intercept the redirected response with an onHeadersReceived handler, but this never triggers as “Only requests made using HTTP or HTTPS will trigger events” and my redirect uses the moz-extension:// protocol.
How does one set response headers when serving web_accessible_resources?
Is it possible at all?
I am developing a project which can disable a particular REST URI at runtime so that consumers will get an error. I have created interface/controller for disabling a URI. But I can not figure out how to disable it.
I thought of setting disable flag for the URI and sending blank data, but consumer needs to see an error.
I can not use Response every where.
Need Help
Implement a ContainerRequestFilter(more on filters), which when a specific criteria is met will call:
ContainerRequestContext.abortWith(javax.ws.rs.core.Response)
with a proper HTTP status code.
I need to intercept HTTP request done by Firefox to set an additional header to the request (like described here: https://developer.mozilla.org/en-US/docs/Setting_HTTP_request_headers) - but I only want to do this if a Javascript resource is requested (or, equivalent, the request got triggered by an <script>tag).
In case of Javascript this sadly cannot be done via looking at the set "accept-encoding" header because this is set to "/".
I already analyzed the objects I get handed over when a request is done - but I cannot find the needed information in there.
Does anybody know how one can detect this?
Looking through some legacy code I have in front of me using struts one, I see:
<global-forwards>
...
<forward name="accessDenied" path="/www/jsp/AccessDeniedForm.do" redirect="true" />
</global-forwards>
So it's just a global forward to send to a access denied page.
I am curious about the decision to redirect as opposed to forward. What are the advantages and disadvantages of using it?
What are the pro's and con's of using it?
Before discussing pro's and con's of using that forward element with redirect set to true, let's understand what is actually going on with that configuration. When redirect is set to true in the forward element, a redirect instruction should be issued to the user-agent so that a new request is issued for this forward's resource. This link will probably provide detail information that you need.
The default value for redirect is to false, essentially when the forward element is called, it forward to that path specified and that's it. If you are setting redirect to true, take for example, the browser will make another request. So I think with these said, you probably know or have an idea the pro and con if you really want to use it.
In redirect, the control can be directed to different servers or even another domain name.The redirect takes a round trip.When a redirect is issued , it is sent back to the client , and redirected URL information is in the header instructing the browser to move to the next URL. This will act as a new request and all the request and response data is lost.
In forward , the forwarding is done from server side , the client browser URL do not change.the data is also not lost.It is just like a browser page refresh. Whatever data posted in the first submit is resubmitted again.So use it with caution.
Both forward and redirect are used in different scenarios ,the global forward should be redirect because it is an error situation.
Redirect is slower as it needs a roundtrip.Forwards are faster.
If you specify
redirect="true", Struts uses a client-side redirect
[response.sendRedirect()]
. The JSP will be invoked by a new browser request, and any data stored in the old request will be lost.
I already seen some question from here (stackoverflow) and THIS post, but I still have some questions...
Using hidden value in the post form and check it when post reach the server.
The hidden value can easy be copied and send exactly like the real one, "hard to guess" (like md5) will not help. (right?)
Setting a cookie when you reach the form and send the cookie value as a hidden value.
You can easily change a cookie value or send a custom cookie exactly like the real one using the same real hidden value. (right?)
Using 'timeout', the POST values cannot reach too late.
So, if you're slow you will fail when you try to set everything up with the hidden value. If you're fast it gonna work. (right?)
I want to be protected about CSRF...but how exactly I do it?
The easiest way I found to prevent CSRF issues is:
On the server side, assign an HttpOnly cookie to the client with a random (unguessable) token
Place a hidden field on the form with that cookie value
Upon form submit, ensure the hidden field value equals the cookie value (on the server side of things)
If you make the following changes then I think you're safe
no data updates should be allowed through GET (or better POST as well) (since both can be used through HTML forms)
disable CORS on your server (or at least on endpoints that are critical and/or make changes to data)
allow JSON-only APIs (ie. only accept input through JSON on critical endpoints at least)
Just to add to above: Do not use method overrides and do not support old browsers.