So I am creating cookies using Perl's CGI module, and I do it as so:
my $cookie = CGI::Cookie->new(-name => "$name",
-value => "$val",
-expires => "$expiration_date",
-path => $cookie_path,
-secure => 0
);
print "Set-Cookie: $cookie\n";
And the cookie is set in the browser, the only issue is that the time does not match up with the expiration date I put. For example, if I put +1d for expiration date, it really does something like +1d - several hours. I checked my system time to see if that was the issue, but my system time is right. Then I printed out the cookie and I got this:
Actual Time of cookie creation: 6/4/2012 12:10:02 PM
COOKIE: session_id=534fec49c864d8cf0325779b0921b6be1338829802484; path=/; expires=Tue, 05-Jun-2012 17:10:02 GMT
The strage thing above is that I record the actual time of cookie creation with perl's 'localtime(time())' function, but it records a different time than what my date command puts out (so not the actual current time)! And then the expiration time on the cookie is actually correct, but it's in the wrong time zone.
So my server is in the eastern timezone when I run the date command:
Mon Jun 4 12:05:12 EST 2012
However, the cookie is being set with GMT as the timezone, and I think this is the issue. Is there another time I should be setting on the server besides just date? I'm running on CentOS 5 if that helps at all. Thanks!
Those times are actually equivalent (12:00 EST is 17:00 GMT). Note that cookies are required, by the specification, to specify the expiry time in GMT. Your browser, in turn, is required to automatically convert the time zone back.
In so many words: everything is happening as it should.
but it records a different time than what my date command puts out
That's not true.
Tue, 05-Jun-2012 17:10:02 GMT
and
Tue, 05-Jun-2012 12:10:02 EST
are different representations of the exact same time. There's no problem. There would be a problem if you had gotten
Tue, 05-Jun-2012 17:10:02 EST
or
Tue, 05-Jun-2012 12:10:02 GMT
But you didn't.
GMT is used because "EST" is ambiguous — there's a time zone in Australia with the same name — and because only one time zone needs to be known instead of all of them if everyone uses GMT.
Related
When making a HTTP(S) request, the response contains the header "Date" with the format day-name, day month year hour:minute:second GMT
I am using Django (3.2) with DjangoRestFramework (3.12) and I want to know if it's possible to change the format of this date.
For example, I want to use this format for my django server: "YYYY-MM-DDTHH:mm:ss"
When using python3.6 requests module
import requests
resp = requests.get('https://stackoverflow.com/')
print(resp.headers['Date'])
# 'Tue, 27 Sep 2022 13:31:25 GMT'
So I think it is not possible to change the format of this date.
But I somehow found a solution to my problem by adding a middleware that sets a new header to my response, with the wright format
When I decode my JWT token I see in payload
{
"exp": 1494105589
}
What does it value means? Docs says that default JWT expiresIn value is "1d" but it's not seems like 1 day after token created and even not 1 day in ms (1000*60*60*24). And the worst: this value not changed much when I set "expiresIn": "90d" in my config. Could somebody give some explanation of this?
it's a unix timestamp, counting the seconds since 1st of January 1970 00:00 UTC.
There are several websites that help you to convert the value, eg. this one : http://www.unixtimestamp.com/index.php
For your timestamp it says 05/06/2017 # 9:19pm (UTC), so your token is valid for 5 month.
https://www.rfc-editor.org/rfc/rfc7519#section-4.1.4
explains that a numeric date is used for the exp claim (and also for the nbf (not before) and iat (issued at) claims)
https://www.rfc-editor.org/rfc/rfc7519#section-2
defines the numeric date:
A JSON numeric value representing the number of seconds from 1970-01-01T00:00:00Z UTC until the specified UTC date/time, ignoring leap seconds.
beside that you said
And the worst: this value not changed much when I set "expiresIn":
"90d" in my config.
when you got the token, did it come in a structure like this :
{"access_token": "eyJhbGciOiJ...", "token_type": "bearer", "expires_in": 86399 }
and if yes, did expires_in show the correct value ?
I was quite frustrated with IPN testing. Although in the end I was able to pin point the issue in Validate step timestamp field, I need help with how to handle the + sign in time stamp.
I noticed when I decode and encode, the space from Paypal request became + sign. So I did a replacement of + with %20. This was tested okay. However it would be an issue if there is timezone info inside the payment date.
E.g. Fri Jul 08 2016 10:22:01 GMT+0800 (Malay Peninsula Standard Time)
parameter came in as:
Fri%20Jul%2008%202016%2010%3A22%3A01%20GMT+0800%20%28Malay%20Peninsula%20Standard%20Time%29
after decoding:
Fri Jul 08 2016 10:22:01 GMT 0800 (Malay Peninsula Standard Time) <=====the plus sign is missing.....
encode again:
Fri+Jul+08+2016+10%3A22%3A01+GMT+0800+%28Malay+Peninsula+Standard+Time%29
What I did was: replay the + sign before decoding with some temp placeholder. then once decode / encode, revert back the replacement.
Some how this could not be verified by Paypal.
Okay, I got it working....not sure whether it's the best way, but works now.
basically I patch the incoming parameter value by replacing + with a placeholder.
patchedValue = value.replace("+", "TEMPXXX");
....
In the end, after encoding, replace the placeholder with %2B, which is + sign.
....
URLEncoder.encode(decodedValue, encoding).replace("+", "%20").replace("TEMPXXX", "%2B")
I am wondering how to determine the age of a web site (not the age of the host / domain registration) in a robust and universal way.
Take this site as an example:
Most of the times, the age / date (December 21, 2011, in this case) appears on the site, but AFAIK there is no universal way of getting this information from the page (could be on the page, in the META-tag, header...)
If you google the headline, Google will show the age (first result; gray; so Google extracted this information somehow):
http://i.stack.imgur.com/BcXwo.png [I don't have privileges to embedd this as an image]
Alongside, there are other sites with the same news (i guess it's from a press agency) and Google shows the age for those as well, but not for the last one, despite its occurrence in the text (First line; Wednesday, December 21, 2011).
Q1) How to determine the age in a universal way?
Q2) How does Google do it? Is it just the time the URL showed up in the index? Why isn't there a date then for the last result?
Q3) If there is no other way then actually getting it from Google, how can that be done automatically for a couple of domains? After a number of automated requests, Google will block / prevent you from sending more requests. I had a look in the Google Custom Search API, but the data does not show up in the results there.
Thanks!
If the server supports it you can use the Last-Modified Header part of the HTTP-Request.
try: curl -I http://online.wsj.com/article/SB10001424052970204058404577110380555673036.html
to get only the HTTP-Header of the Reply and have a look at the output
HTTP/1.1 200 OK
Date: Wed, 09 May 2012 12:40:10 GMT
Server: Apache/2.2.15 (CentOS)
...
FastDynaPage-ServerInfo: secj2kentwap07 - Wed 05/09/12 - 08:40:10 EDT
Last-Modified: Wed, 09 May 2012 12:40:10 GMT
Content-Type: text/html; charset=UTF-8
Actually I haven't found a proper way to get the date from the URL. So I took another approach: I try to find a feed (either from the site itself or through Google) that contains that URL as an item.
Then there is a good chance that I'll either get a pubDate or dc:date which contains the date of publication. This is then usable.
Thanks for all the input.
I have a Perl-based website that attempts to set a number of cookies on the users first visit and I just noticed that Safari has stopped setting all but the first cookie that is passed. On first visit two cookies should be set which are 'location' and 'referrer'. In IE and Firefox the cookies are being set correctly but Safari is only setting the 'location' cookie. I tried changing the names, values, etc. and the conclusion I've come to is that Safari is just setting the first of the two cookies:
Here is the code that is setting the cookies:
# Add location cookie if necessary
if(!$query->cookie('location') && $user_location) {
my $cookie = $query->cookie(-name=>'location',-value=>qq|$user_lcoation|,-domain=>".domain.com",-path=>'/',-expires=>'+1Y');
push(#cookies,$cookie);
}
# Add referrer if first visit
if(!$query->cookie('referrer')) {
if($ENV{'HTTP_REFERER'}) {
my $cookie = $query->cookie(-name=>'referrer',-value=>$ENV{'HTTP_REFERER'},-domain=>".domain.com",-path=>'/',-expires=>'+3M');
push(#cookies,$cookie);
}
else {
my $cookie = $query->cookie(-name=>'referrer',-value=>'unknown',-domain=>".domain.com",-path=>'/',-expires=>'+3M');
push(#cookies,$cookie);
}
}
if(scalar(#cookies)) {
print $query->header(-cookie=>\#cookies);
}
Here is what I get when I try to access the website from curl:
curl -so /dev/null -D - http://domain.com
HTTP/1.1 200 OK
Date: Thu, 18 Feb 2010 20:19:17 GMT
Server: Apache/2.0.63 (Unix) mod_ssl/2.0.63 OpenSSL/0.9.8e-fips-rhel5 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635 PHP/5.2.8 mod_perl/2.0.4 Perl/v5.8.8
Set-Cookie: location=Dallas; domain=.domain.com; path=/; expires=+1Y
Set-Cookie: referrer=unknown; domain=.domain.com; path=/; expires=Wed, 19-May-2010 20:19:20 GMT
Transfer-Encoding: chunked
Content-Type: text/html; charset=ISO-8859-1
Any ideas? I'm at a loss as to what I can do to help resolve this issue since it seems that my script is passing them correctly. Thanks in advance for any insights or ideas you might have!
Look at the expires date on the first cookie header -- it's a literal +1Y instead of the actual standard datestamp that it should be. My guess is that your version of Safari is choking on this and simply refuses to parse the remaining cookie headers.
To set a one-year expiration date, the correct syntax is -expires => '+1y' (lowercase Y).
Try upgrading CGI.pm (do cpan CGI). I had similar problem with cookies that was solved by CGI.pm upgrade.
a bit late for an aswer, but later better than never :
a simple way, without having to reinstall/update CGI.pm, is to specify the date you
want your cookie to expire, using DateTime.pm :
my $cookie = CGI->new->cookie(
-name=>'cookie_name',
-value=>'value',
-domain=>$ENV{'HTTP_HOST'},
-expires=>((DateTime->now->set_time_zone('local'))->add(months=>1)->strftime("%a, %d %b %Y %I:%M:%S GMT")),
-path=>'/',
);
there i've got a cookie that will last for 1 month.
I tested it on safari under XP, works fine.
hope this will help