I want to be able to detect when a response from the backend contains this:
testCookie="ASF#ED124312FASdf23er="; Version=1; Max-Age=0; Expires=Thu, 01 Jan 1970 00:00:10 GMT; Path=/; Secure
What I want to detect is that the response is going to set the expiration date to 01 Jan 1970 for the cookie called testCookie.
The challenge is in the fact that haproxy when using a fetch method to get a header, will consider commas as the delimiter for separate values. and the alternative proposed, which is to use fhdr to fetch the complete header indeed works but will not enable you to filter for a specific Set-Cookie header via a regex filter or something, so you have to rely on a fixed index of the Set-Cookie header to be fetched....and that is not acceptable obviously.
So, I have tried:
ACL with regex
acl is_expiration hdr_reg(Set-Cookie) <enter_regex_here>
This has the downside that the comma in the expiration date will cause haproxy to parse that value in 2 separate parts so you can either match the first part which gives you the correct cookie identifier or the second part which has the expiration date.
Full Header with var and separate acl
http-response set-var(txn.temp_var) res.fhdr(Set-Cookie)
acl is_expiration var(txn.temp_var) -m sub 01\ Jan\ 1970
This will store the whole text in the Set-Cookie header in a temporary value and then I can do a substring match on that, or a regular expression but I still run into the problem of the comma and this is approach is error prone because it will take the first Set-Cookie header found or one found at a specific index I can specify.
Workaround
I could match by the Max-Age but if the server implementation changes and Expires and Max-Age switch places, I am screwed.
acl is_expiration hdr_reg(Set-Cookie) testCookie.*Max-Age=0
So.....heeeeelp!!!
After getting my head a bit out of the issue itself, I found an answer showing how the synthax should look like for an ACL using the full header fetch command.
Bottom line....the documentation is kind of quirky and the solution looks like this:
acl is_expiration res.fhdr(Set-Cookie) -m reg testCookie.*Expires=Thu,\ 01\ Jan\ 1970
Related
Actually I want to set header like this
response()->json($data)->header('Set-Cookie','strCookie1',false)->header('Set-Cookie','strCookie2',false)->send();
But the Set-Cookie not shown in the header.
Is there any way to set the cookie in Lumen 5.6
I saw the withCookie(cookie()) but not sure how to use. The cookie() in Lumen is not defined.
Note: I need 2 set-cookie at the same time, and the strCookie1 is already the full long string of the cookie value.
(Like this: TOKEN=abcxyz; Path=/; Expires=Sun, 24 Mar 2019 03:40:11 GMT; Max)
Thank you.
According to documentation here:
However, for most routes and controller actions, you will be returning a full Illuminate\Http\Response instance. Returning a full Response instance allows you to customize the response's HTTP status code and headers. A Response instance inherits from the Symfony\Component\HttpFoundation\Response class, providing a variety of methods for building HTTP responses:
You can find the appropriate method to set cookie here. The argument is either string or a Symfony\Component\HttpFoundation\Cookie instance. If you see the code inside it (here's the link), the string argument only accepted when the
cookie function is defined. In this case, it's not defined. So this method only leaves you one option:
To supply the first argument with an instance of
Symfony\Component\HttpFoundation\Cookie
<?php
use Symfony\Component\HttpFoundation\Cookie;
$response
->withCookie(
new Cookie($name, $value, $expire)
);
I understand that I can use url_param / urlp to extract the query parameters from the URL that is requested, in HAProxy.
However, I need similar function for extracting parameters from the URL sent as HTTP Header field Referer. I guess url_param is only available for the requested URL, and not possible to use for HTTP Header values? If so, what other options do I have? I need to retrieve the value from query parameter and send it as specific HTTP Header to the backend server.
Sharing my solution (although Im not sure this is the most efficient and accurate way). I solved it with Regex.
# Example HTTP Referer: http://myexample.com/users?user-id=12345
# ACL
acl is_uid_in_hdr_referer hdr_sub(Referer) -i user-id
# Set value from query param "user-id" from Referer header to custom header "user-id"
http-request set-header user-id %[req.hdr(Referer),regsub(.+?user-id=,,g)] if is_uid_in_hdr_referer
I am following this MSDN Reference (https://learn.microsoft.com/en-us/rest/api/storageservices/fileservices/put-block) to implement a rest call for Put Block.
I am coding in Java and I formed below Authorisation string and URL before signing.
PUT
364070
x-ms-blob-type:BlockBlob
x-ms-date:Fri, 20 Jan 2017 12:57:06 GMT
x-ms-version:2016-05-31
/xyz/mycontainer/imageBlock1
comp:block
sun.net.www.protocol.https.DelegateHttpsURLConnection:https://xyz.blob.core.windows.net/mycontainer/imageBlock1?comp=block&blockid=YmxvY2stMQ==
Error I am getting:
403
Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature.
I read gaurav mantras post http://gauravmantri.com/2013/02/16/uploading-large-files-in-windows-azure-blob-storage-using-shared-access-signature-html-and-javascript/. But, its not working for me.
Is there anything wrong with the string I am sending to sign or URL or
below httpConn Request Header.
The Http Header I am setting is:
httpConn.setRequestMethod("PUT");
httpConn.setRequestProperty("x-ms-blob-type", blobType);
httpConn.setRequestProperty("x-ms-date", date);
httpConn.setRequestProperty("x-ms-version", storageServiceVersion);
httpConn.setRequestProperty("Authorization", authorizationHeader);
httpConn.setRequestProperty("Content-Length",String.valueOf(blobLength) );
System.out.println(httpConn);
DataOutputStream wr = new DataOutputStream(httpConn.getOutputStream());
wr.write(bytes);
wr.flush();
wr.close();
int response = httpConn.getResponseCode();
As I known, Put Block is a operation against Block Blobs. So, we do not need to specify x-ms-blob-type header. If you specify this in your HTTP header, you need to follow the following tutorial about constructing the Canonicalized Headers String:
Retrieve all headers for the resource that begin with x-ms-, including the x-ms-date header.
Convert each HTTP header name to lowercase.
Sort the headers lexicographically by header name, in ascending order. Each header may appear only once in the string.
Finally, append a new-line character to each canonicalized header in the resulting list. Construct the CanonicalizedHeaders string by concatenating all headers in this list into a single string.
So, based on your code, your canonicalized headers string looks like:
x-ms-blob-type:BlockBlob\nx-ms-date:Fri, 20 Jan 2017 12:57:06 GMT\nx-ms-version:2016-05-31\n
Moreover, the CanonicalizedResource you built is incorrect. Based on your code, it should look as follows:
/{account-name}/{container-name}/{blob-name}\nblockid:{block-id}\ncomp:block
Note: For more details about constructing the Canonicalized Resource String, you could refer to this official document.
The StringToSign would look like this:
And the traffic captured by Fiddler as follows:
I've read through RFC 2617 and can't find there or anywhere else what the delimiter is if multiple schemes are supported. For example, suppose both Basic and Digest are supported. I understand that it may appear this way:
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic
WWW-Authenticate: Digest
But I've also read that both can be listed as one line, but no one ever shows an example or describes what delimiter to use. I've seen cautions that commas can be used within a single scheme:
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest param1="foo", param2="bar"
I've also read that if commas are used within a scheme, that other schemes must be placed on separate lines. So I imagine in the above case if we added Basic it would appear like this:
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest param1="foo", param2="bar"
WWW-Authenticate: Basic
That's simple enough. But now suppose you just have one line
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Scheme stuff, morestuff, more stuff
Which is that? Is that a comma-delimited list of schemes, or is that one scheme, with a few parameters?
As far as I can tell, the spec punts on the issue. Section 1.2 states:
Note: User agents will need to take special care in parsing the WWW-
Authenticate or Proxy-Authenticate header field value if it contains
more than one challenge, or if more than one WWW-Authenticate header
field is provided, since the contents of a challenge may itself
contain a comma-separated list of authentication parameters.
I think we can translate special care to best of luck chap.
Pragmatism
As a practical matter, I suspect multiple schemes means one should use multiple wwww-authenticate headers. Schemes are extensible; e.g., I can come up with a scheme called "strawberry" or "opaque" if I want to be sinister. Given this, there isn't really a good way to parse a one liner without some sort of 'scheme termination' delimiter.
W3C Discussion
You aren't the first person with this question. There was a discussion on the W3C mailing list. The poster stated :
I wasn't questioning the need to provide multiple challenges in a
single response. I was only questioning the wisdom in allowing
multiple challenges in a single header field, given the odd
combination of separators it creates.
Some other threads discussing current issues & future action that may be of interest:
root of above thread
Backwards definition of authentication header
#342 WWW-Authenticate ABNF slightly ambiguous
WWW-Authenticate ABNF is ambiguous
future http 2 - Multi-legged Authentication for HTTP Multiplexing
If only ...
Not that I have the stomach for it, but one could dig through the chromimum, firefox & webkit code to see how those communities have handled the issue.
How should a random number generator properly be implemented in REST?
GET RANDOM/
or..
POST RANDOM/
The server returns a different random number each time.
I can see arguments for both ways.
I'd say this is the same as for a page returned that contains the current time - and many of these are done using GET. Abstractly, fetching a random number (or time) the server's state doesn't change - both time and random numbers can be described as an observation of an external event. E.g. http://random.org use atmospheric noise.
GET seems most appropriate, although caching will need to be disabled via appropriate headers, e.g.
Expires: <Current Time>
Last-Modified: <Current Time>
Cache-Control: no-cache, must-revalidate
Pragma: no-cache
If you want to ensure that the served content is already expired:
To mark a response as "already
expired," an origin server sends an
Expires date that is equal to the Date
header value. (See the rules for
expiration calculations in section
13.2.4.)
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
Definitely GET. Even though it might modify server-side state (if it uses a pseudo-RNG), that's just an implementation detail the client shouldn't care about.
definition of REST-call with GET: the result have to be the same -> not GET.
definition of REST-call with PUT: the result of the call can be repeatable, the server should not have problem with it -> use PUT
POST is the weakest method and can used if other are not useful.
Why not GET: the result of GET-call can be cachet (cache-header, etag oder transparent proxies) and you dont will get random results ...