check XBMC with Arduino - get

A week ago I started a new project with my Arduino MEGA 2560 with Ethernet Shield. I'm able to send a WOL to my server but now I want to PING my XBMC server with the JSON-RPC command. With my Chrome browser I'm able to check the server with follwoing HTTP GET request:
http://192.168.5.34/jsonrpc?request={"jsonrpc": "2.0", "id": 1, "method": "JSONRPC.Ping"}
And as a result I get a clean PONG back from the XBMC server:
{"id":1,"jsonrpc":"2.0","result":"pong"}
Now I tried to do this with my Arduino with the following code that is embedded in a function:
EthernetClient client;
IPAddress server(192,168,5,34);
if (client.connect(server, 80))
{
Serial.println("Connecting to Client...");
client.print("GET /jsonrpc?request={%22jsonrpc%22:%20%222.0%22,%20%22id%22:%201,%20%22method%22:%20%22JSONRPC.Ping%22} HTTP/1.1\r\n");
client.print("Host: 192.168.5.34\r\n");
client.print("User-Agent: Mozilla/5.0\r\n");
client.print("Connection: close\r\n\r\n");
}
else
Serial.println("Client Connection Failed!");
With my Arduino a got following return:
HTTP/1.1 401 Unauthorized
Content-Length: 0
Connection: close
WWW-Authenticate: Basic realm=XBMC
Date: Fri, 06 Jun 2014 21:33:24 GMT
I can make a GET request to Google with my Arduino so it's really XBMC that for some reason does not accept my GET request. Anyone got an idea why? I used Wireshark to sniff the network data on the server and the request and return are present in Wireshark.
Is there maybe a way to login on the XBMC server by GET or POST?
Thanks for the help guys! :)

WWW-Authenticate: Basic realm=XBMC
This means that your server requested your user agent (Arduino in this case) to authenticate using basic access authentication.
Adding this line should do the trick:
client.print("Authorization: Basic xxxxxxxxxxxxxxxxxxxx\r\n");
where xxxxxxxxxxxxxxxxxxxx is Base64 encoded (more precisely RFC2045-MIME variant of Base64 is used, except not limited to 76 char/line) username and password. In order to obtain it, you can use Wireshark to capture this request header while sending request from your browser, or generate it:
Check in your XBMC settings (Settings > Services > Webserver) for the username/password. It is by default xbmc:xbmc.
Go to http://www.motobit.com/util/base64-decoder-encoder.asp and in the first textbox put your username and password using format: username:password, e.g. xbmc:xbmc. Select encode option, change Maximum characters per line: to some big value, e.g. 500 and press Convert the source data.
Copy the Base64 representation (for xbmc:xbmc it will be eGJtYzp4Ym1j and use it in your header, e.g.:
client.print("Authorization: Basic eGJtYzp4Ym1j\r\n");
You can also use https://github.com/adamvr/arduino-base64 library for the base64 encoding.
The reason why it works in your browser is that it may have already been authenticated.

Related

Docusign REST API will not send base64 document to Java client

This has me baffled.
I can request the document content as base64 with curl , no problem.
curl https://demo.docusign.net/restapi/v2/accounts/<id>/envelopes/<id>/documents<id> -H"Authorization : Bearer <token>" -H "Content-Transfer-Encoding: base64" -o <filename>
Return headers are
Content-Disposition: file; filename="blah"; documentid="1"
Content-Transfer-Encoding: base64
and the file is returned in base64 format.
Using the Apache oltu oauth2 library which underneath uses HttpURLConnection I cannot get the response to be sent in base 64. I have the request headers set to
Content-Transfer-Encoding: base64
Accept : */*
Authorisation : Bearer <token>
But all I ever get back is the binary version of the file which ultimately bombs out because the library saves the stream as a string which screws up the pdf.
I can't trace the return header , but the request header definitely has the above fields set.
Is there anything in the Docusign endpoints which look at the User-Agent or anything else to determine whether to do the base 64 encoding ? Why else would it only ever return the binary stream ?
I suspect your Java output is not the same and the best way to confirm this is to capture exact JSON/SOAP request posted by your API calls via Java to DocuSign by following steps explained at this DocuSign support article https://support.docusign.com/guides/ndse-user-guide-api-request-logging
Please post these and I am sure it will be we will be able to deduce the library "add" that is changing the actual output.
OK thanks #david for the advice on logging the requests in docusign. I find that the "Transfer-Content-Encoding" header has mysteriously disappeared on arrival at the Docusign server. Some digging indicates that
a. this header is dodgy anyway for non-email uses and that
b. in the Java HttpUrlConnection class it is "removed" as security measure. You can apparently set some flags to revert to previous behaviour. See https://bugs.openjdk.java.net/browse/JDK-6996110
In any case I worked around the problem by implementing a class which reads the response as an InputStream and not worrying about base64.
Hopefully this helps a Java OAuth library user save a day of their lives banging their heads against a wall !

Does DocuSign Connect work with basic HTTP auth details?

I am using DocuSign connect to update the state of my app after an event happens on a document.
I have set up my account like so:
At the moment my "URL to Publish" looks something similar to https://key:secret#example.herokuapp.com. However when I look in the logs I always seem to receive something similar to:
error: Exception in EnvelopeIntegration.RunIntegration: key :: https://key:secret#example.herokuapp.com/webhook :: Error - The remote server returned an error: (401) Unauthorized
When I copy the Envelope Data into a file locally (complete-webhook.xml) and I run the following command through the command line it seems to run successfully:
curl -i -X POST -d #complete-webhook.xml https://key:secret#example.herokuapp.com/webhook
Has anybody got any ideas as to the reason why this could be happening?
When you use a url such as https://username:password#example.com/, your client takes the username:password part of the url and uses it to create an Authorization: Basic header.
You can try it yourself, create a requestb.in and then use the curl command
curl -X POST -d "fizz=buzz" http://username:password#requestb.in/12345
# where 12345 is your requestb.in address
The result on requestb.in:
A request to just /12345 (the incoming url does not include the username or password)
The request includes the header Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=
If you put dXNlcm5hbWU6cGFzc3dvcmQ= through a base64 decoder, you get username:password
Answer, at this point, the Connect system does not support sending basic authentication information when it calls listeners. I have filed an internal feature request.
Work-around
Your listener url can include a query parameter that serves as a password. eg. `example.com/webhook/?pw=9e47a953-c105-44c5-ba5c-4bb77d63694d
Then, in your listener, simply reject any request that does not include the pw query parameter and the value that you chose.
In its requests to your listener, the Connect system will use any query parameters that you originally set when you added the Connect subscription.

Amazon S3 Query String Authentication Cancels The Download?

I'm building an app in NodeJS that stores files in Amazon S3 using the Knox S3 client. Everything works well for uploading files, moving files around, etc.
Now I want to use the Query String Authentication mechanism to allow direct downloads of the files. To do this, I have some code on my NodeJS server call to the Knox library and create a signed url.
The code looks like this:
exports.getS3Policy = function(file) {
var date = moment().add("min", 60).toDate();
var expires = new Date(date.getUTCFullYear(), date.getUTCMonth(), date.getUTCDate(), date.getUTCHours(), date.getUTCMinutes(), date.getUTCSeconds());
return knoxClient.signedUrl(file, expires);
};
This code returns a proper URL with the authentication parameters. For example:
https://my-bucket.s3.amazonaws.com/some/folder/file.ext?Expires=1234567890&AWSAccessKeyId=ABCDEFGHIJKLMNO&Signature=someEncodedSignature
According to all of the documents I've read, this is a proper URL. I'm not getting any errors from Amazon with this url. The expiration is correct (I can verify this by creating an expiration of 1 second and then getting an expired error). The file path is correct, as well.
When I hit the url in my browser, though, my browser (latest Chrome on OSX) cancels the download of the file, even though I'm getting a 200 ok response with the right file information.
Here is a copy of the request info from Chrome dev tools (sensitive bits replaced):
Request URL:https://my-bucket.s3.amazonaws.com/some/folder/file.ext?Expires=1234567890&AWSAccessKeyId=ABCDEFGHIJKLMNO&Signature=someEncodedSignature
Request Method:GET
Status Code:200 OK
Request Headers
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8
Cache-Control:no-cache
Connection:keep-alive
DNT:1
Host:my-bucket.s3.amazonaws.com
Pragma:no-cache
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.65 Safari/537.36
Query String Parameters
Expires:1234567890
AWSAccessKeyId:ABCDEFGHIJKLMNO
Signature:someEncodedSignature
Response Headers
Accept-Ranges:bytes
Content-Length:341390
Content-Type:application/octet-stream
Date:Tue, 10 Sep 2013 13:22:55 GMT
ETag:"fc4d24e752097f212e111f2736af7162"
Last-Modified:Tue, 10 Sep 2013 01:40:31 GMT
Server:AmazonS3
x-amz-id-2:some-id
x-amz-request-id:some-request-id
As you can see, the server response is "200 ok". The content-length of 341390 is also the correct lenght of the file I'm attempting to download - this is the actual file size. I'm getting the content type as "application/octet-stream" because that's how I told S3 to store the files... I just want the raw download, basically.
But after getting this response from S3, Chrome cancels the download. Here's a screencap from devtools, again:
FireFox and Safari both download the file as expected. Why is chrome canceling the download? What am I doing wrong? Is it the content type? or ?
Of course I find the answer as soon as I post the question... it's a bug in Chrome
https://code.google.com/p/chromium/issues/detail?id=104331
The fix will be available starting with Chrome/Chromium 30.x. Please
open a new issue if you are seeing similar issues with versions of
Chrome 30 or above.
The supported means of indicating that a resource must be downloaded
is to use the Content-Disposition header field
(https://www.rfc-editor.org/rfc/rfc6266).
Looks like I have to get S3 to set a content-disposition in the response.

Chromecast "StartApplicationRequest failed with status: -4"

I've set up the Chromecast SDK, whitelisted my device, and am running web servers at the URLs I provided in the whitelist request.
The chromecast tic tac toe app works fine with the default app id "TicTacToe", however changing it to my own: "1813060e-33c5-41dc-b356-0d2bad12497f" or "1813060e-33c5-41dc-b356-0d2bad12497f_1" does not work.
The server url is up and running at http://chromecast.clockworkmod.com/, but no requests are being made to it by Chromecast. The chromecast doesn't display anything. However I get a few errors in the log.
Here is the logcat.
W/StartSessionTask(15590): StartApplicationRequest failed with status:
-4 E/ApplicationSession(15590): StartSessionTask failed with error: failed to start application: request failed D/GameActivity(15590):
start session failed: failed to start application: request failed
I've also tried using the internal app id with the dev url I had provided, http://192.168.1.2:3000/
I found the answer here:
unable to cast to personal whitelisted receiver app
Using the Chromecast app on my Macbook, I went into Settings.
Send serial number when Checking for updates
Reboot device the device using the Mac update app
This resolved the error for me. The chromecast doesn't know if it is whitelisted unless you send the serial during update checks.
I think I see what's missing! In your receiver you gave a link to, you have:
var receiver = new cast.receiver.Receiver(
'GoogleCastSampleApp',
[cast.receiver.RemoteMedia.NAMESPACE],
"",
5);
But it should be (fill in the 'YOUR APP ID HERE' with your App ID)
var receiver = new cast.receiver.Receiver(
'YOUR APP ID HERE',
[cast.receiver.RemoteMedia.NAMESPACE],
"",
5);
I am running into the same error as well. I after setting the Chromecast to send the serial when checking for updates I was finally able to access the debugger one port 9222. Unfortunately, I don't see anything happen on the Chromecast at all when I select it from the device list on my Nexus and try sending one of the demo videos.
Something I noticed and I don't know it makes difference or not but if you whitelist a domain in the GoogleCast extension for Chrome and you include the "http://" it will cause the injection to not work. I wonder if this is the problem with the look up that the Chromecast performs as I submitted my URLs to Google with the http:// prepended. Again I am not sure this should really make a difference but I plan on trying to resubmit the URLs just to see.
Install cURL in your windows machine from here
Now make sure that your device and laptop are in same network.
Now go to command prompt, type curl -d "" http://:8008/apps/YouTube
there If it gets casted automatically to TV then instead of YouTube put your appid and try.
If not then your router is blocking some traffic.

Windows Azure - Set Blob Service Properties REST API Call Authentication parameter

I am trying to make a simple REST call to the Set Blob Properties API (http://msdn.microsoft.com/en-us/library/windowsazure/hh452235) to just turn off/on logging. I have gotten the REST API call to successfully work for retrieving Blob Properties, so I know my hashing algorithms, headers-setting, and Authentication signature creation works, but I can't seem to get it working on the Set Properties side of things. I keep getting an error on the Authentication Header, so I know I'm not doing something right there.
I have copied below what is being created and eventually hashed and put into the auth header string. The online documentation (http://msdn.microsoft.com/en-us/library/windowsazure/dd179428) does not really help in determining which of these fields are absolutely required for this particular type of Blob request, so I've tried filling most of them in, but I don't seem to get a difference response regardless of what I fill in. I've also tried the Shared Key Lite authentication, which would be preferred since it's much more lightweight, but that doesn't seem to work either when I fill in all 5 of those fields.
Shared Key Authentication for Blob Services:
PUT\n
\n
\n
130\n
(MD5_CONTENT_HASH)
\n
\n
\n
\n
\n
\n
\n
x-ms-date:Tue, 19 Jun 2012 19:53:58 GMT\n
x-ms-version:2009-09-19\n
/(MY_ACCOUNT)/\n
comp:properties\n
restype:service
Is there anything obvious I'm missing here? The values (MD5_CONTENT_HASH) and (MY_ACCOUNT) are of course filled in when I make the request call, and the similar request call to "GET" the properties works fine when I send it. The only difference between that one and this is that I'm sending the MD5_content, along with the content-length. I may be missing something obvious here, though.
Any advice would be greatly appreciated! Thanks in advance.
-Vincent
EDIT MORE INFO:
Programming Language I'm using: Objective-C (iOS iPhone)
I'm also using ASIHTTPRequest to make the request. I simply define the request, setRequestMethod:#"PUT", then I create the request body and convert it to NSData to calculate the length. I attach the request-body data via the appendPostData method to the request. I then build the auth string above, hash the whole thing, and attach it to the request as a header called "Authorization".
Request Body String I'm using:
<?xml version=\"1.0\" encoding=\"utf-8\"?><StorageServiceProperties><Logging><Version>1</Version></Logging></StorageServiceProperties>
I know this is an incomplete request body, but I was planning on waiting for it to give a failure on "missing request body element" or something similar, until I proceeded on creating the full XML there. (could that be my issue?)
Error I get from the server:
<?xml version="1.0" encoding="utf-8"?><Error><Code>AuthenticationFailed</Code><Message>Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature.
RequestId:accc4fac-2701-409c-b1a7-b3a528ce7e8a
Time:2012-06-20T14:36:50.5313236Z</Message><AuthenticationErrorDetail>The MAC signature found in the HTTP request '(MY_HASH)' is not the same as any computed signature. Server used following string to sign: 'POST
130
x-ms-date:Wed, 20 Jun 2012 14:36:50 GMT
x-ms-version:2009-09-19
/(MY_ACCOUNT)/
comp:properties
restype:service'.</AuthenticationErrorDetail></Error>
What's odd is that the error I get back from the server seems to look like that, no matter how many parameters I pass into the Authentication signature.
Thanks for any help you can offer!
Comparing your signed string and the error message indicates that you're sending a POST request but signing as though you're sending a PUT.

Resources