I am trying to clear two cookies in my clients browser via the following:
this.response.set('Set-Cookie', 'mycookie1=; Path=/; expires=Thu, 01 Jan 1970 00:00:00 GMT; ,mycookie1.sig=; Path=/; expires=Thu, 01 Jan 1970 00:00:00 GMT;');
I can only seem to get rid of mycookie1 and not the mycookie.sig.
It's more about the protocol (HTTP). You should split it into two header fields (Set-Cookie for each cookie).
By RFC6265:
An origin server can include multiple
Set-Cookie header fields in a single response. ... Origin servers SHOULD NOT fold multiple Set-Cookie header fields into
a single header field.
There is a better way to set cookies with Koa than the raw way, two cookies are set by call it simply twice (see the docs for the possible options):
function *() {
this.cookies.set('mycookie1', 'value1', options);
this.cookies.set('mycookie2', 'value2', options);
}
Related
I want to generate a file and upload it to disk like a file.
I unload as
ServletResponseUtil.sendFile(httpServletRequest, httpServletResponse, fileName, baos.toByteArray(), ContentTypes.APPLICATION_OCTET_STREAM);
As a result, the file is not uploaded as a file to disk, but to the browser page as
�� ࡱ �; �� V ���� ������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������Root Entry �������� �FW� Workbook ������������ !� SummaryInformation( ���� D
Responce headers
HTTP/1.1 200
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Cache-Control: private, no-cache, no-store, must-revalidate
Pragma: no-cache
Liferay-Portal: Liferay Community Edition Portal 7.2.0 CE GA1 (Mueller / Build 7200 / June 4, 2019)
Content-Disposition: attachment; filename="test.xls"
Content-Type: application/octet-stream;charset=UTF-8
Content-Length: 46080
Date: Tue, 24 Dec 2019 07:21:40 GMT
That most likely happens because you're running this code within an action- or render-method of your portlet. Portlets render only fragments of HTML pages that will always be embedded in a proper HTML page. If you mock with that by obtaining the HttpServletRequest and (more specifically) HttpServletResponse, you'll just mix the portal's rendered output with your own.
You should use the serveResource method to host your implementation, there you don't even need to revert back to the HttpServletResponse, but can just stream your output to the RenderResponse.
Even if you don't end up with mixed HTML/XLS content but see only the actual XLS output, you might interfere with Liferay's SPA loader, which you can assume knows about expected return values, e.g. when rendering, it expects a HTML portal page, not binary data. That will not be the case when you use the serveResource method, as it is expected to return arbitrary Mimetypes.
I've discovered a domain name (web site and API) which adds a header like this to each HTTP response:
XTVOpalL: Gtm; path=/; Max-Age=900
The header name looks random. Here are few other examples:
XRQOJalT: LtZ; path=/; Max-Age=900
XYjOzalA: Ntx; path=/; Max-Age=900
XykOMalm: ytD; path=/; Max-Age=900
Note the leading 4 spaces. And compare to other response headers:
HTTP/1.1 301 Moved Permanently
Date: Sat, 05 May 2018 11:52:25 GMT
Server: Apache
Location: http://example.com/wp/
Content-Length: 229
Content-Type: text/html; charset=iso-8859-1
Set-Cookie: visid_incap_993094=GuEL85vzTDKQUJ9jfphhgvma7VoAAAAAQUIPAAAAAACgWz3NlkG3smvkXeB6Ewyl; expires=Sun, 05 May 2019 08:21:45 GMT; path=/; Domain=.example.com
Set-Cookie: nlbi_993094=z0NWEcMl0wAVBr8CiwzebQAAAACu2KRRlrUCoWpyWKTrUAJF; path=/; Domain=.example.com
Set-Cookie: incap_ses_115_993094=/xoUXc5Kags3fAFBHpCYAfma7VoAAAAABT/i1XAh1J4D/02wGnXO9w==; path=/; Domain=.example.com
Set-Cookie: ___utmvmicuVtwf=peInjtBXhca; path=/; Max-Age=900
Set-Cookie: ___utmvaicuVtwf=wYxmyOU; path=/; Max-Age=900
Set-Cookie: ___utmvbicuVtwf=TZr
XYjOzalA: Ntx; path=/; Max-Age=900
X-Iinfo: 13-63374213-63374214 NNNN CT(222 -1 0) RT(1525521145044 0) q(0 0 2 0) r(5 5) U11
X-CDN: Incapsula
Main problem - this header sometimes is the first header in the response. Which, in turn, is considered a vulnerability.
In my case it looks like this:
HTTP/1.1 301 Moved Permanently
XYjOzalA: Ntx; path=/; Max-Age=900
Date: Sat, 05 May 2018 11:52:25 GMT
Server: Apache
Location: http://example.com/wp/
...
Quoting the RFC of HTTP 1.1 https://www.rfc-editor.org/rfc/rfc7230#section-3
A sender MUST NOT send whitespace between the start-line and the first header field.
...
The presence of such whitespace in a request might be an attempt to
trick a server into ignoring that field or processing the line after
it as a new request, either of which might result in a security
vulnerability if other implementations within the request chain
interpret the same message differently. Likewise, the presence of
such whitespace in a response might be ignored by some clients or
cause others to cease parsing.
This results in node.js throwing error trying to parse these HTTP responses. Error code is HPE_INVALID_HEADER_TOKEN, which is thrown only if HTTP headers are malformed.
Question: What is it? Who's doing it? Why?
"What is it?"
This is a bug in server side, as it violates HTTP protocol.
Actually, it was discussed in HTTP working group in 2013 for "a bug into python library", and I think the conclusion by Julian Reschke is correct:
It's not a legal field name, thus not a legal start of a header field line.
...
It's forbidden by the grammar, so it's invalid.
"Who's doing it? Why?"
When developer generate the random HTTP header name, he/she introduces this 4-whitespace leading characters, by accident.
I am sending a POST request with sockets and trying to decode the received HTML and print to the terminal.
This works fine in my initial GET request but when I try to decode and print the POST request I just get garbled text.
How can I change my decode so that the text is readable?
POST
POST
body = "hash="+md5
headers = """\
POST / HTTP/1.1\r
Host: url.com:57555\r
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:66.0) Gecko/20100101 Firefox/66.0\r
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r
Accept-Language: en-US,en;q=0.5\r
Accept-Encoding: gzip, deflate\r
Referer: http://url.com:57555/\r
Content-Type: application/x-www-form-urlencoded\r
Content-Length: 32\r
Connection: close\r
Cookie: PHPSESSID=some_cookie\r
Upgrade-Insecure-Requests: 1\r
\r\n"""
payload = headers + body
s.sendall(payload.encode('utf-8'))
res = s.recv(4096)
print(str(res, errors='replace'))
Result...
python3 emdee5.py
HTTP/1.1 200 OK
Date: Sun, 26 May 2019 22:01:26 GMT
Server: Apache/2.4.18 (Ubuntu)
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 282
Connection: close
Content-Type: text/html; charset=UTF-8
]�1o� ���
ʒ��Ҩ��b�V��LN��
p�$����Py��d��FP��l� ^�֞i�ĜmA��F7i�zd}��VͩK8}ߠ���!�n�W>�wL9ۅr�#Ȑ����� 4i��ec{"%��0���)������W���A�I��"��GD�;�܉"J��JA}x��l1��3٠.y�>Om�#5��9
��ڨ�p�j����JN���MQ̀)�:�p�P{K���4J^-��+�7�oV'E;'=�����l�
Your request explicitly says that you are willing to accept a compressed response:
Accept-Encoding: gzip, deflate\r
And this is therefore what you get in the response
Content-Encoding: gzip
So, the body is compressed with gzip (which explains the garbled output) and you would need to decompress it. Given that you currently don't seem to be able to properly deal with compressed responses you should not claim in your request that you support these, i.e. remove the Accept-Encoding.
Apart from that more is likely wrong with your request:
body = "hash="+md5
...
Content-Length: 32\r
...
payload = headers + body
...
Given that md5 is 32 characters hex (or 16 byte binary) the body consisting of "hash"=+md5 is likely not 32 characters long as you claim in your Content-Length.
POST / HTTP/1.1\r
Additionally you send a HTTP/1.1 request so you have to be able to deal with chunked responses - but your code does not deal with these.
res = s.recv(4096)
Similarly your code blindly assumes that the full response can be retrieved within a single recv which does not need to be the case.
In summary: unless you have a deeper understanding of how HTTP works (which you do not seem to have) it is recommended that you use existing libraries to handle HTTP for you, since these were written by developers who have an understanding of HTTP.
And even if you already have an understanding of HTTP you'll likely will use these libraries anyway since you'll know that HTTP is far from trivial and that it makes no sense to implement all the necessary details and edge cases by yourself in your code if something robust already exists.
audit=value1; Version=1; Max-Age=31535999; Expires=Thu, 25-Jul-2019 17:20:26 GMT,c=1; httponly; Path=/
I am beginner in python. I have a string that contains the http.response.set_cookie captured using wireshark. I want to parse the cookies and save them in the database.
I used the code suggested by falsetrue in Python - convert set-cookies response to array of cookies
but unfortunately I did not know how to retreive the other cookie parameters like "httponly" ,"domain","secure"
Appreciate any help!
Thanks.
Title pretty much explains my problem. If this isn't possible, how can I write my own IDs? Specifically, how do I generate an ID string that I know isn't currently taken by Couch then I can do the string append myself and save it.
You can use an update handler to combine a prefix of your choosing and an automatically generated UUID. An update handler basically intercepts an HTTP request, does some additional transformation and returns the new document. (and a message to be sent in response to the user)
In an update handler, the req object is also given the UUID that CouchDB would have assigned to the document. If there is no existing document for the current request, you can create a new one entirely from scratch.
function (doc, req) {
// if no document exists
if (!doc) {
// create a new one
doc = {
// req.id is the generated UUID for this request
_id: "article_" + req.id
};
}
// always return an array 1) the new doc and 2) the string response message
return [ doc, "New Article Created" ];
}
The example here is really trivial, and more complete examples are given in that wiki page that I linked to. I just wanted to show you nothing more than what you needed for your question. Update handlers are a very powerful way to implement some application logic at the database layer.
I prefer Dominic's answer but for completeness, you could also pre-load a bunch of UUIDs from CouchDB and combine them yourself. To get a batch of five:
$ curl -i example.iriscouch.com/_uuids?count=5
HTTP/1.1 200 OK
Server: CouchDB/1.2.0 (Erlang OTP/R15B)
Pragma: no-cache
Expires: Fri, 01 Jan 1990 00:00:00 GMT
ETag: "86908CQ9GCBC01P6VF18YM2P4"
Date: Sun, 12 Feb 2012 02:03:23 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 187
Cache-Control: must-revalidate, no-cache
Connection: keep-alive
{"uuids":["da769daee5996412c8f598155c002885","da769daee5996412c8f598155c0034b4","da769daee5996412c8f598155c00406f","da769daee5996412c8f598155c004c18","da769daee5996412c8f598155c00501a"]}
Now you can compose your own IDs. You have more work ahead of you, to write and maintain the code to do all this. But the advantage is that you do not need an update function, executing a Javascript function (and potentially spawning a Javascript process on the server) for every document update.
Personally, I would start with Dominique's technique and only move to mine if/when you hit performance problems.