steve8x8 / geotoad

Geocaching query tool written in Ruby
https://buymeacoffee.com/steve8x8
Other
28 stars 8 forks source link

authentication fails (with Ruby 1.9.1) - Windows/Ruby1.9 feedback please #247

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
I'm trying to get geotoad running on my Synology NAS. This is the ruby version:

$ ruby --version
ruby 1.9.1p243 (2009-07-16 revision 24175) [arm-linux-eabi]

The TUI is working OK, but when I launch the query, geotoad fails during the 
authentication step.

I've attached a debug.log and the default.aspx from the geotoad cache.

I'm using geotoad v3.17.0 from the SVN.

Original issue reported on code.google.com by magic...@gmail.com on 8 Jun 2012 at 7:26

Attachments:

GoogleCodeExporter commented 9 years ago
Hmm.

I'm pretty sure it's not a matter of the Ruby version. (Did you succeed with 
1.8.7?)

Which GeoToad version did you use before?
When did it stop working?
What files are in your .geotoad directory, and when have they been last written 
to?
(I.e., have you been using "cookie" instead of "cookies.yaml"?)
(Does cookies.yaml contain a username: cookie_string line that looks good?)

If you have a valid cookie (in your browser, for example) you may try to 
"transplant" it into cookies.yaml, and check again.

There have been some small changes lately to gc.com which _might_ be suited to 
stop one from getting a new cookie (a situation that's rarely tested...)

Original comment by Steve8x8 on 8 Jun 2012 at 9:24

GoogleCodeExporter commented 9 years ago
I'm sorry, but I cannot reproduce the issue (even after removing the cookie 
from the cookies.yaml file).

With an existing cookie:
D: using cookie ["me"] ASP.NET_SessionId=osya1**************wlgvx
D: setting local expiry to 1
D: Checking validity of cookie (ASP.NET_SessionId=osya1...wlgvx)
D: cachefile: .../GeoToad/www.geocaching.com/login/default.aspx
D: ====+ Fetch URL: https://www.geocaching.com/login/default.aspx
D: ====+ Fetch File: .../GeoToad/www.geocaching.com/login/default.aspx
D: no local cache file found for 
.../GeoToad/www.geocaching.com/login/default.aspx
D: sleep 1.0 seconds
D: Fetching URL [https://www.geocaching.com/login/default.aspx]
D: using cookie ["me"] ASP.NET_SessionId=osya1**************wlgvx
D: Added Cookie to https://www.geocaching.com/login/default.aspx: 
ASP.NET_SessionId=osya1**************wlgvx
D: GET to /login/default.aspx, headers are User-Agent Accept Accept-Language 
Accept-Charset Referer Cookie
D: https://www.geocaching.com/login/default.aspx successfully downloaded.
D: creating .../GeoToad/www.geocaching.com/login
D: outputting .../GeoToad/www.geocaching.com/login/default.aspx
D: Returning 40045 bytes:
<!DOCTYPE html>
<h(...)>
</body>
</html>
D: post URL is https://www.geocaching.com/login/default.aspx
D: found hidden post variable: __EVENTTARGET
D: found hidden post variable: __EVENTARGUMENT
D: found hidden post variable: __VIEWSTATE
D: Found login confirmation!
D: saveCookie: ["me"] ASP.NET_SessionId=osya1**************wlgvx

- the existing cookie got re-used

Without a cookie line matching "me" account:
D: Looks like we don't have a valid cookie. Must login.
D: saveCookie: no cookie, will delete
D: saveCookie: ["me"]
D: setting local expiry to 1
D: cachefile: /.../GeoToad/www.geocaching.com/login/default.aspx
D: ====+ Fetch URL: https://www.geocaching.com/login/default.aspx
D: ====+ Fetch File: /.../GeoToad/www.geocaching.com/login/default.aspx
D: local cache is only 0 (<= 1) sec old, using local file.
D: 46679 bytes retrieved from local cache
...
D: SET ctl00$ContentBody$tbUsername: me
D: SET ctl00$ContentBody$tbPassword: (hidden)
D: SET ctl00$ContentBody$cbRememberMe: on
D: SET ctl00$ContentBody$btnSignIn: Login
D: added post vars to url: 
https://www.geocaching.com/login/default.aspx-P=c34545f5ee3197935820b132db5389cc
D: cachefile: 
/.../GeoToad/www.geocaching.com/login/default.aspx-P_c34545f5ee3197935820b132db5
389cc
D: ====+ Fetch URL: https://www.geocaching.com/login/default.aspx
D: ====+ Fetch File: 
/.../GeoToad/www.geocaching.com/login/default.aspx-P_c34545f5ee3197935820b132db5
389cc
D: no local cache file found for 
/.../GeoToad/www.geocaching.com/login/default.aspx-P_c34545f5ee3197935820b132db5
389cc
D: sleep 1.0 seconds
D: Fetching URL [https://www.geocaching.com/login/default.aspx]
D: /home/steffen/.geotoad is being used for config
D: Loading cookies from /home/steffen/.geotoad/cookies.yaml
D: using cookie ["me"]
D: No cookie to add to https://www.geocaching.com/login/default.aspx
D: POST to /login/default.aspx, headers are User-Agent Accept Accept-Language 
Accept-Charset Referer Content-Type
D: received cookie: ASP.NET_SessionId=btkry**************lrqse; path=/; 
HttpOnly, userid=e4cf5a6a-21c4-4b89-aabb-b59850a11a91; domain=.geocaching.com; 
expires=Sun, 08-Jul-2012 09:40:17 GMT; path=/; HttpOnly
D: saveCookie: ["me"] ASP.NET_SessionId=btkry**************lrqse

which in turn can be used during the next run...

I'm puzzled.

Original comment by Steve8x8 on 8 Jun 2012 at 9:48

GoogleCodeExporter commented 9 years ago
I don't have ruby 1.8.7 available on the NAS. In fact, geotoad always threw 
that error message in the past when I tested it, it's only now that I'm 
reporting it. :-) So I guess that's not related to recent changes to gc.com.

The .geotoad directory is pretty empty, apart from the config.yaml (and the 
.../default.aspx).

I also just tried copying the coookie and cookies.yaml files from my other 
Linux (Intel, ruby 1.8.x) box into the .geotoad directory, but that didn't 
help, the error message still occured. The cookies in those file have been used 
last night during a scheduled query on that machine.

I just modified auth.rb to print all the lines that are parsed in 
"getLoginCookie" and the error occurs when trying to match this line:

<li><a id="ctl00_uxLocaleList_uxLocaleList_ctl02_uxLocaleItem" 
href="javascript:__doPostBack('ctl00$uxLocaleList$uxLocaleList$ctl02$uxLocaleIte
m','')">Français</a></li>

Could that also be related to a missing UTF-8 (or whatever) library/support on 
my NAS box!?

Original comment by magic...@gmail.com on 8 Jun 2012 at 9:59

GoogleCodeExporter commented 9 years ago
I did a bit of investigation and this simple patch fixes the issue for me:

Index: geotoad.rb
===================================================================
--- geotoad.rb  (revision 1164)
+++ geotoad.rb  (working copy)
@@ -15,6 +15,8 @@
 end
 if RUBY_VERSION.gsub('.', '').to_i >= 190
   $isRuby19 = true
+
+  Encoding.default_external = Encoding::UTF_8
 end

 # toss in our own libraries.

Original comment by magic...@gmail.com on 8 Jun 2012 at 6:42

GoogleCodeExporter commented 9 years ago
Thanks for working this out - what are your locale settings?
(Shouldn't Encoding.default_internal be set to UTF_8 as well?)

May I have some feedback from Windows users?

In the long run, GeoToad will need Ruby 1.9 (1.8 will be phased out in June 
2013) - which brings the whole set of Encodings stuff. For packaging reasons, 
the Windows executable is based on 1.8.7 - should I force 1.9 at least for the 
development series,
to get UTF-8 things sorted out in time?

Original comment by Steve8x8 on 25 Jun 2012 at 12:43

GoogleCodeExporter commented 9 years ago
The suggested patch has been incorporated into 3.16.1 - now I'd like to get 
some feedback from Windows/Ruby1.9 users...
Citing from my request in the Google Group:
- which OS you're using, and which locale
- the output of        ruby -v
- the output of        ruby -e 'p [Encoding.default_external, 
Encoding.default_internal]'
- the hex dump of  "äöü߀" if you can produce these characters within 
your command shell ("echo äöü߀ | hexdump -C" for Linux etc.) - or the 
file containing the characters itself

Original comment by Steve8x8 on 29 Jun 2012 at 10:53

GoogleCodeExporter commented 9 years ago
As an answer to comment #5, here's what I see on the Linux NAS that was causing 
the initial problems:

ruby 1.9.1p243 (2009-07-16 revision 24175) [arm-linux-eabi]
[#<Encoding:US-ASCII>, nil]

I think I had also tried setting Encoding.default_internal, but removed it 
again as it didn't have any effect. I.e. the line in the patch was enough to 
fix it for me.

Original comment by magic...@gmail.com on 6 Jul 2012 at 8:59

GoogleCodeExporter commented 9 years ago
There seems to be at least one Windows user running Ruby 1.9.3 who didn't 
report any problems. Probably it's time to close this one.

Original comment by Steve8x8 on 4 Sep 2012 at 8:30