Closed transitive-bullshit closed 8 years ago
They've started asserting a new header value that I haven't implemented yet for security reasons (we have a way to generate this value but it doesn't use SSL and requires login info, which means sending that over an unencrypted network).
Try changing .digest9_14
to .digest9_12_2
in SKClient.m and change the Snapchat user agent version from 9.14.0.0
to 9.12.2.0
in SnapchatKit-Consants.m
Thanks for the quick turnaround Tanner -- that solved it!
Mind giving me some more info on this new header?
btw, my node port is fairly complete at this point with almost all endpoints having working unit tests. Would love to have the same type of unit test setup for SnapchatKit.
Sure thing!
I don't know much about it, but the header field name is X-Snapchat-Client-Auth-Token. I'll eventually add its use as an optional toggle to the SKClient class. I don't know much about how it works sadly, just that someone I know has a server that will generate it properly.
How are you unit testing the endpoints? Are you recording real responses? Unit tests are on my to-do list, haha.
Tanner Bennett
On Aug 20, 2015, at 11:29 PM, Travis Fischer notifications@github.com wrote:
Thanks for the quick turnaround Tanner -- that solved it!
Mind giving me some more info on this new header?
btw, my node port is fairly complete at this point with almost all endpoints having working unit tests. Would love to have the same type of unit test setup for SnapchatKit.
— Reply to this email directly or view it on GitHub.
Not recording real responses. I'm just hitting each endpoint with reasonable data and making sure the response doesn't error. For some things like addFriend, I update the session and ensure that the new friend is indeed in the list of friends.. but most of them are just signin, then fire off a bunch of requests that should succeed unless some invariant has changed.
Some of the tests only test internal functionality, like taking a public story, downloading the media_url and ensuring that the resulting SKBlob correctly decrypts and decompresses the data w.r.t. the story key & iv.
See here for a list of the unit test types.
Relevant to this thread:
I've just started running into this error when signing in on the latest version of SnapchatKit. Link to screenshot
Any ideas?
Snapchat cut support for earlier versions of the app, so now we must sign in using 9.14.0.0. I tried to push a new version of the cocoapods today but cocoapods is giving me trouble (as usual). The code in master is working now though. Go to releases and read the warning for 0.3.2.
Tanner Bennett
On Aug 31, 2015, at 6:41 PM, Kiran Panesar notifications@github.com wrote:
Relevant to this thread:
I've just started running into this error when signing in on the latest version of SnapchatKit.
Any ideas?
— Reply to this email directly or view it on GitHub.
The insecure part is in sending it to http://casper.io? How come we need to rely on a remote server to generate the client auth token?
Because we don't know how they're making it, but we have the compiled code that does so, so we host it on a server to do it for us.
Tanner Bennett
On Aug 31, 2015, at 6:50 PM, Kiran Panesar notifications@github.com wrote:
The insecure part is in sending it to http://casper.io? How come we need to rely on a remote server to generate the client auth token?
— Reply to this email directly or view it on GitHub.
Got it. Is there somewhere we can find the compiled code for this?
Email the owner of the site, Liam Cottle. It's called libscplugin.so
Tanner Bennett
On Aug 31, 2015, at 7:20 PM, Kiran Panesar notifications@github.com wrote:
Got it. Is there somewhere we can find the compiled code for this?
— Reply to this email directly or view it on GitHub.
@ThePantsThief couldn't Liam just add basic encoding of the username & password as POST params instead of using query params?
Sending in the POST body would not ensure secure transfer. The POST body is just as accessible as the URL parameters. Setting up Casper.io's API with HTTPS would do the trick though.
I'll talk to him about it :) Surprisingly enough, I don't know much about networking… I'll get back to you soon!
Tanner Bennett
On Aug 31, 2015, at 7:59 PM, Kiran Panesar notifications@github.com wrote:
Sending in the POST body would not ensure secure transfer. The POST body is just as accessible as the URL parameters. Setting up Casper.io's API with HTTPS would do the trick though.
— Reply to this email directly or view it on GitHub.
@KiranPanesar by encoding as POST params, I meant encrypting with some shared public key similar to how snapchat's internal auth tokens are encrypted & decrypted.
SSL would be great, but I really don't think we should be relying on Liam's server for this. I'd much rather see Liam open source a wrapper around libscplugin.so that we could host ourselves.
@ThePantsThief do you know if the PHP API relies on libscplugin.so as well or casper's servers?
It seems the PHP library has the same dependency :-/
As far as we know, no one knows how it works so everything will rely on it on an external server somehow. Once someone figures it out I will of course update SnapchatKit to generate the value locally
Tanner Bennett
On Aug 31, 2015, at 8:22 PM, Travis Fischer notifications@github.com wrote:
@KiranPanesar by encoding as POST params, I meant encrypting with some shared public key similar to how snapchat's internal auth tokens are encrypted & decrypted.
SSL would be great, but I really don't think we should be relying on Liam's server for this. I'd much rather see Liam open source a wrapper around libscplugin.so that we could host ourselves.
@ThePantsThief do you know if the PHP API relies on libscplugin.so as well or casper's servers?
— Reply to this email directly or view it on GitHub.
Wow, Liam actually just updated his server to use HTTPS… I'll have it updated sometime this week!
Tanner Bennett
On Aug 31, 2015, at 8:30 PM, Travis Fischer notifications@github.com wrote:
It seems the PHP library has the same dependency :-/
— Reply to this email directly or view it on GitHub.
Heya,
I setup SSL on the Casper server about 4 days ago.
Certificate was purchased for 3 years, so won't have to worry about that for a while...
The old endpoint was http://client-auth.casper.io
and the new one supporting SSL is: https://api.casper.io/security/login/signrequest
Example Request (GET
and POST
supported)
https://api.casper.io/security/login/signrequest/?username=test&password=lol×tamp=1234567890
{
"code": 200,
"signature": "v1:4030c24b72563b83da57f18c:e849ef6e59d6bb36bb6b354cc2e68a6e5549c8b893c223e14c5ea46d9368818a6c51e97be55990b7b349838554e30819",
"server": "clientauth-1-NYC1",
"android_latency": 160
}
Output if Android Emulator Server is offline etc:
{
"code": 503,
"server": "clientauth-2-NYC1",
"message": "Signing Service Unavailable"
}
EDIT:
Just an insight on why all the GitHub libs are using my server at the moment.
At this stage, the native libraries used to sign the login request can only run within an Android system.
We've tried a ton of methods to get the native libs to work on Linux without the need for Android.
Such as replacing libs that it depends on with non-android versions, and looking through the assembly code of the libs...
No luck yet, however, what my server does, is runs an Android Emulator, which acts as an HTTP Server.
When the Linux server receives an HTTP request, it forwards it onto the Android Emulator, which runs an Android application that I wrote which is an HTTP Server for interacting with the native libs.
The login details passed in the HTTP request are then passed into the native lib, and the output signature is wrapped in JSON and output as the HTTP Response.
The reason this didn't originally have SSL, is because it's running on the Android device itself.
The Casper API server now has SSL, and acts as a proxy. Making a request to the Android Emulator via an Internal IP Address (since it's in the same data centre).
It's all pretty tedious stuff, but hey... Snapchat want it this way.
Liam, my man
Tanner Bennett
On Sep 1, 2015, at 1:55 AM, Liam Cottle notifications@github.com wrote:
Heya,
I setup SSL on the Casper server about 4 days ago.
Certificate was purchased for 3 years, so won't have to worry about that for a while...
The old SSL endpoint was http://client-auth.casper.io and the new one is: https://api.casper.io/security/login/signrequest
Example Request (GET and POST supported)
https://api.casper.io/security/login/signrequest/?username=test&password=lol×tamp=1234567890 { "code": 200, "signature": "v1:4030c24b72563b83da57f18c:e849ef6e59d6bb36bb6b354cc2e68a6e5549c8b893c223e14c5ea46d9368818a6c51e97be55990b7b349838554e30819", "server": "clientauth-1-NYC1", "android_latency": 160 } Output if Android Emulator Server is offline etc:
{ "code": 503, "server": "clientauth-2-NYC1", "message": "Signing Service Unavailable" } — Reply to this email directly or view it on GitHub.
@liamcottle thanks for the thorough breakdown -- super helpful && sounds like a very reasonable approach.
Is there any chance the Android Emulator portion and HTTP server Android app could be open sourced so the PHP/ObjC/Node clients could remove the dependency on casper.io? It'd still require an external server to be hosted, and casper.io could be the default, but any non-trivial application that depends on these libs really can't be expected to rely on your servers.
About network there is also a bug:
when parse the url to casper, if user's name or password contains "#", the contents after "#" will be dropped, maybe 'urlencode' should be made before request by url.
@ruozi that issue will be fixed once @ThePantsThief makes the switch to use SSL & post parameters.
I've already fixed it, I'm POSTing to his URL with the params in the http body and it works. It'll be in 0.3.3 :)
Ah, awesome!
Not sure what could be causing this, but both SnapchatKit and my node port are now failing to authenticate with 401 errors on the
/loq/login
route.I've tried multiple Snapchat accounts and tried different IP addresses. Can anyone else confirm whether or not the library is working on their end?