2 things: 1. In your man-in-the-middle script, change
$headers[0] = "Accept-Encoding: gzip"; $headers[1] = "Content-Type: text/xml"; to $headers[0] = "Content-Type: text/xml"; .... you're getting a gzipped version of their TOS. 2. From now on, add this in the middle of the login request: <member><name>agree_to_tos</name><value><string>true</string></value></member> e.g. <member><name>platform</name><value><string>Mac</string></value></member> <member><name>mac</name><value><string>0123456789abcdef0123456789abcdef</string></value></member> <member><name>id0</name><value><string>0123456789abcdef0123456789abcdef</string></value></member> <member><name>agree_to_tos</name><value><string>true</string></value></member> <member><name>viewer_digest</name><value><string>5a49d5d2-5120-d345-1788-91e2afd66798</string></value></member> -b On Thu, 29 Jun 2006 11:55:27 -0700, "John Hurliman" <[EMAIL PROTECTED]> said: > [EMAIL PROTECTED] wrote: > > I believe I have figured out the problem, and I'm sad to report it looks > > like this will require more code in libsecondlife. This was a result of the > > TOS being displayed upon login. In order to continue with login you had to > > accept the terms of the TOS. This is not currently handled in > > libsecondlife. When I accepted the TOS via the normal client, I was able to > > use libsecondlife afterward. Unfortunately, I did not think to gather data > > during the process. So I'm unsure how we can implement this in > > libsecondlife. This could be a problem for development of a daemon that > > remains logged in, and logs in after new patches automatically. > > > > -Sam > > > > > > > For a large part of the development process it's been only one or two > devs writing code, so we've been skipping anything that isn't > immediately necessary. However, since more people are submitting patches > these days this is one that could be attacked. The ToS agreement is some > sort of XML-RPC exchange during the login, you're going to create a new > account and log it in through a logging proxy to dump the client / > server exchange. Might be worthwhile to get two dumps, one for accepting > and one for denying. I've attached my PHP logging proxy, upload it > somewhere, create a file called output.txt in the same directory with > appropriate write permissions, and tell the client to use it with > -loginuri http://url.com/login-proxy.php. I think there is a bug in it > right now, where it's dumping the SSL encrypted response from the server > instead of plaintext, you'll have to look in to it. The good news is we > recently switched to using an actual XML-RPC library instead of building > the exchange by hand so this should be a piece of cake once a login dump > or two have been made. > > John Hurliman _______________________________________________ libsecondlife-dev mailing list libsecondlife-dev@gna.org https://mail.gna.org/listinfo/libsecondlife-dev
