2013-11-14 HotFix caused: new issues with login script

[GoogleCodeExporter]

What steps will reproduce the problem?
[Please include the relevant parts of your command line, if applicable.
Don't send your password though!]
1. geotoad (for Windows), ./geotoad.rb (MacOS X, Linux)
2.
3.

What is the expected output? What do you see instead?
[If possible, include the last ~10--20 lines of verbose output.]

Expected output is that login is successful; instead, apparently the cookie IS 
being accepted but it redirects to the account profile page throwing an error 
about an incorrect username and password.  (Of note, this is NOT the normal 
behaviour that it has done in past, nor is it the result when one logs in with 
either Firefox or Chrome on an HTTPS login.  I AM able to browse and search 
caches normally on the page, so this may be something Geocaching.com has done 
to lock out "unblessed" clients OR we just may need to tweak the login 
script--they ARE allowing login by Facebook now, which could be confusing the 
script.)

What version of the product are you using? On what operating system?
[Did you check you're using the latest version?]

Have tried on Windows 7 Home 64-bit (Geotoad 3.18.1 both from prebuilt on site 
AND from source using Ruby for Windows 1.9); MacOS X 10.7.5 Lion (from present 
source tree); Linux (Linux Mint 1.6 "Petra" MATE, from source tree).

Please provide any additional information below.

Probably just needs a minor tweak re the login script--will play with things 
later to see if there's a fix  

Original issue reported on code.google.com by windigo...@gmail.com on 16 Nov 2013 at 3:02

[GoogleCodeExporter]

For a while, GeoToad had only parsed, used, and stored the (ASP.NET) SessionId 
cookie. This doesn't seem to be enough anymore - there's a "userid" and (this 
is really new) "gspkuserid" cookie now.
Looking closer at cookie handling: it doesn't seem very clever to me anymore :(

I'll try to wireshark the stuff ASAP - and try to make GeoToad behave (more) 
correctly again.
This may mean that there will be no 3.18.2 at the end of the week as planned - 
this change may instead justify a version bump to 3.19 (and some delay? I'm 
afraid - I'm rather busy with my real life at the moment).

Any contribution is welcome.

Priority deserves a +2 as this apparently affects usability badly.

- S

Original comment by Steve8x8 on 17 Nov 2013 at 12:49

• Changed title: 2013-11-14 HotFix caused: new issues with login script
• Changed state: Accepted
• Added labels: Priority-High
• Removed labels: Priority-Low

[GoogleCodeExporter]

OK, apparently the culprit is the new gspkuserid (which stays the same over 
subsequent "clear" logins).
I have started to rewrite the cookie handling code - which still needs a lot of 
cleanups. Attached is this first version of a patch against the current SVN 
trunk head.
Please test and give feedback - don't criticize the code too much yet ;)

Original comment by Steve8x8 on 17 Nov 2013 at 5:47

• Changed state: Started

Attachments:

• 288-login_cookies.diff

[GoogleCodeExporter]

Here's another attempt, this time silencing the (normal) output a lot.
I'm currently running my usual tests with it, and it looks rather promising... 
YMMV, of course. (If so, please share.)

Original comment by Steve8x8 on 17 Nov 2013 at 7:46

Attachments:

• 288-login_cookies.diff

[GoogleCodeExporter]

A quick test worked for me (Premium account). Will continue testing, too.

Original comment by magic...@gmail.com on 19 Nov 2013 at 11:13

[GoogleCodeExporter]

Here's the Release Candidate of the patch. It still lacks deleting of expired 
cookies, and doesn't use the cookies.yaml file (but the code is still in there).
Patch changes lib/auth.rb and lib/shadowget.rb (start with the 3.18.1 or trunk 
versions)

Original comment by Steve8x8 on 19 Nov 2013 at 4:06

Attachments:

• 288a-login_cookies.diff

[GoogleCodeExporter]

it works for me, have just tried with a regular account, but now i can download 
mine ad my friends caches again! and all caches nearby

ruby geotoad.rb -u xyzzy -p xyzzy-c traditional -x csv -q location 'xyzzy' -y 
50 -o caches.txt
ruby geotoad.rb -u xyzzy -p xyzzy -z -x csv -q user xyzzy  -o friends/xyzzy.txt 

Original comment by and...@vannman.nu on 20 Nov 2013 at 4:48

[GoogleCodeExporter]

Okay... since 3.18.1 has been downloaded more than 600 times (!) in the past 
month, the user base seems to justify an early bugfix release. 3.19.0 will be 
out later today - with still some room for improvement, certainly, but it'll be 
better than nothing at all. Stay tuned! Uploading the fix this moment...

Original comment by Steve8x8 on 20 Nov 2013 at 7:33

• Changed state: FixAvail

[GoogleCodeExporter]

Hello,
I have unfortunately no idea how to handle the diff files and the SVN trunk so 
I can not test it. Would it be possible to have a wiki (step by step) how to do 
it? Otherwise all people like me have to wait for an official new version.

I am using the windows version 

Original comment by erwin123...@gmail.com on 20 Nov 2013 at 7:51

[GoogleCodeExporter]

If you use the WindowsInstaller version, there's actually no way to patch 
things unless you set up your own build environment (including the Ocra gem and 
InnoSetup).
But you wouldn't replace the pistons in your car's engine on your own, just 
following instructions on a Wiki page (or on YouTube), right?

But your request is valid - for those who know what "SVN" means and what 
"patch", there should be a small chapter in the manual (see Issue 282) "How to 
keep up with development". Basic knowledge of a minimal toolset would still be 
required, I think.

3.19.0 is in the final phase right now and will be out later today. For you, 
and 500+ other users.

Original comment by Steve8x8 on 20 Nov 2013 at 9:17

[GoogleCodeExporter]

Hi, one comment from my side.

I have several error messages like:

***  GCXXXX was parsed, but no coordinates found

One of these caches is Jucy bean http://coord.info/GC3Z1HH

It is no Members Only cache ???

Original comment by erwin123...@gmail.com on 21 Nov 2013 at 8:42

[GoogleCodeExporter]

#10 is unrelated to this issue, and cannot be reproduced without additional 
information (language settings of both your GC account, and your OS - try to 
set them to English). 

Original comment by Steve8x8 on 22 Nov 2013 at 9:48

[GoogleCodeExporter]

Another remark (#10):
In some places anonymization does make no sense at all if you want your problem 
to be reproduced. Cache GCXXXX does exist (although in a completely different 
region, and has been archived several years ago).
Performing a search around the coordinates of "Jucy bean" (I won't tell you my 
command line as long as you don't tell me yours; sorry, privacy first) I indeed 
find one
   ***  GC3EHF4 was parsed, but no coordinates found.
and that's a PMO cache, indeed.

Closing the original Issue thread.

Original comment by Steve8x8 on 22 Nov 2013 at 10:32

• Changed state: Fixed

[GoogleCodeExporter]

#12 ???
I wrote "several error messages" this means not only one can be mentioned BUT 
the cache
"Juicy bean" with code GC3Z1HH is one of it ... so it is no Premium Cache
So where do you think I am hiding some information?

My OS has a different language as Groundspeak but why is it working for the 
most caches?

I did the request via the User Interface so there is no commandline text 

Original comment by erwin123...@gmail.com on 22 Nov 2013 at 8:15