 A1Premium
join:2005-08-28
PA | reply to DogFace05
Re: [Proggy] Google Voice dialer I also get "GALX" using both IE 8 and Chrome 3.0.195.25. |
|
| reply to skyhook
said by skyhook:This is what I get: name="GALX" It's what I get, too, and what I search for in version 0.70.0--assuming that it's what everyone would have. However, the error message that wklink reported, indicates that the value isn't found in his/her case, so it seems that it could vary perhaps. |
|
| reply to OmagicQ
I'm using IE 6, as well, but have no problem viewing the source. I have no idea what would cause the option to be greyed out in your case. |
|
|
|
 skyhookPremium
join:2004-06-30
Columbus, OH
1 edit | reply to DogFace05
This is what I get:
name="GALX"
-----------------------------
Reason for edit - pasted wrong value. |
|
OmagicQPosting in a thread near you
join:2003-10-23
Bakersfield, CA
kudos:1 Reviews:
 ·voip.ms
·callwithus
·Callcentric
| reply to DogFace05
unable to view source |
|
|
| reply to wklink
The value name="_rnr_se" comes from an entirely different page, only after having succesfully logged in. That's not the value I'm asking for. What I'm looking for is a value from the link I stated--without logging in at all. Do not even try to log in. If you have logged in, log off and browse to that link again. Then view the source without trying to log in. |
|
| reply to DogFace05
name="_rnr_se" |
|
| reply to wklink
Browse to https://www.google.com/voice/m using Internet Explorer, and in the browser's menu, select View->Source. About halfway down the source, you'll find the following HTML code:
<input type="hidden"
name="XXXX"
value="yyyyyyyyyyy" />
<input type="text" name="Email" id="Email"
size="18" value=""
Let me know what the 'name="XXXX"' statement is in your case, instead of "XXXX". Note that "XXXX" is just a dummy placeholder, and not the actual letters you'd expect to find there. Do not post or tell me the associated 'value="yyyyyyyyyyy"' assignment. |
|
| reply to DogFace05
gvdial-0-70-0 doesn't work for me. Instead, I get:
Error: Could not establish session key. |
|
dalrun
join:2008-01-09
Bellingham, WA | reply to DogFace05
said by DogFace05:The 302 response is an HTTP redirect. An HTTP parser will normally follow any redirects, until it either errors out or gets a successful response. To get a successfull response, the parser needs to know what to do with the response it gets  . The 302 was unexpected and now I have to wait for it to happen again before I know that my cookie reset works.
Cookies get set at both »www.google.com/accounts/ServiceL···dcentral) and »www.google.com/voice/m (the m/mobile page is smaller). Those pages only need to be visited to (re)set the cookies.
You are right that there is no plain test expires= in any of the cookies. At this point I have no idea why I've had to reset the cookies once in the last couple? of months. |
|
| reply to OmagicQ
said by OmagicQ:Does the change made by Google affect sipsorcery? I don't know if they user your dialer or thier own. I've never looked into any of SipSorcery's products, so I haven't the remotest clue what they base their GV dialing on. |
|
| reply to pagemen
said by pagemen:How to check if the GV cookie is expired? or it never expires? In my case, I do login and recreate cookie everytime, needless to say, this adds some delay but works fine. Would be great if there is some way to check cookie validity first and speed the process. If your dialer uses wininet.dll to handle the HTTP, you can take advantage of a wide range of functions provided by that DLL for inspecting and manipulating cookies. Last I checked, the particular cookie in question did not have any expiration set. However, there's nothing to prevent GV from abandoning that cookie at any time, for instance, in favor of a renamed cookie.
For my GV channel driver for Asterisk, I use OpenSSL in conjunction with my own home brewed HTTP parser and cookie manager. It runs through the web processing significantly faster (even on a measly embedded router) than my original dialer. However, most of the delay in setting up a call, seems to be at GV's end, after the call request has been issued. |
|
| reply to dalrun
The 302 response is an HTTP redirect. An HTTP parser will normally follow any redirects, until it either errors out or gets a successful response. Google Voice's login process goes through a series of redirects, each of which adds or removes certain cookies. If the right cookies aren't set, the login never succeeds. Google presumably do this to guard against simple dialers that do not have the built-in intelligence to process redirects and cookies. Any dialer based on a full fledged HTTP parser, that properly manages cookies, should work fine.
My dialer uses wininet.dll, IE's HTTP parser engine. What made it fail, was that it would go directly to the login URL, bypassing the login page. By "login page", I mean the page that presents the login prompt. That page, when logging in, does a POST method request to the "login URL", which (and any associated redirects) is where the login authentication actually takes place. That worked fine until Google started setting a cookie in the "login page" that gets checked during the login process.
Merely browsing to "http://www.google.com/voice" with IE, results in the cookie being set. It is not necessary to login, or even enter anything in the email or password fields. Since I can't remember the last time I logged in to GV's site with IE (when I browse there, it's always with another browser), it isn't strange that it affected my particular use of the dialer. Likewise, anyone who normally does not use IE, could expect to run into the same issue (with the original dialer). |
|
| reply to OmagicQ
My Sipsorcery Google Voice calling has not been affected. |
|
OmagicQPosting in a thread near you
join:2003-10-23
Bakersfield, CA
kudos:1 | reply to pagemen
Does the change made by Google affect sipsorcery? I don't know if they user your dialer or thier own. |
|
| reply to dalrun
How to check if the GV cookie is expired? or it never expires? In my case, I do login and recreate cookie everytime, needless to say, this adds some delay but works fine. Would be great if there is some way to check cookie validity first and speed the process. |
|
dalrun
join:2008-01-09
Bellingham, WA | reply to A1
I don't know what caused it, but I was getting a 302 response a couple? of weeks ago and deleting my saved cookies (custom LWP based dialer, no IE) fixed it. I've had no problem reusing the cookies since. |
|
A1Premium
join:2005-08-28
PA | reply to DogFace05
I've never used IE to log into GV and the original gvdial works as usual, just tested it. |
|
| reply to curro
It looks like within the past week, Google put in place some attempt to stop scripted dialers, by setting a cookie/variable at the login page, that has to be there when logging in. Any dialer that attempts to login without first having visited the login page to pick up this value, will fail. By simply browsing to the login page, IE's persistent cookie manager picks it up, and after that, my program seems to work fine (as it uses IE's HTTP engine behind the scenes). However, just in case, I've made and attached an update that always visits the login page first. |
|
curro
join:2003-10-24
Seabrook, TX Reviews:
 ·Clearwire Wireless
| reply to DogFace05
said by DogFace05:It means it can't connect to google's server. The program uses Internet Explorer's connection settings, so you have to make sure that those are set correctly. Ok, I was getting the same error as Saltine (my account is not with a Gmail domain). Then I logged to my GV account once using IE and after that the dialer works. There is probably an explanation for this but I wanted to share my experience.
Great job Mr. DogFace05! It is appreciate it very much. |
|
