Jump to content

Issue with API Keys after fresh install of 3.5.2.0


bpbenich

Recommended Posts

bpbenich

I seem to be having a weird issue with issuing API keys after a fresh install of 3.5.2.0.

It seems that API keys are somehow not persistent and are only valid for one-time use. After creating an API key, I am able to successfully use it once, but if I try again it fails and the API key had disappeared from the API key list immediately after the first successful use. 

 

For some context:

I'm in the process of upgrading from Warden jail plugins to iocage jails. Everything seems to be running as normal and I am just trying to connect Sonarr and a custom written web interface that use API keys. I'm currently on FreeNAS 11.2-STABLE train with a fresh 11.2-Release FreeBSD iocage jail, with Emby installed with the new FreeBSD pkg. I don't see a reason for it to be a FreeNAS/FreeBSD issue so I am posting on General topics. On my previous Warden Plugin Jail, originally created on FreeNAS train 9.10.2-U4 and running 3.4.1.0, in the context of API keys, worked perfectly fine and normal. After the fresh install of 3.5.2.0, I did do a restore of users, settings, etc. from 3.4.1.0 with the Emby backup & restore plugin.

 

Attached is my log. Last thing I did was create an API key and use it for one http post and now it no longer shows on the API list. The http post was done through my web interface, I attempted to login via AuthenticationByName with user Guest and was successful.

Log.txt

Edited by bpbenich
Link to comment
Share on other sites

bpbenich

what happens when you try to use it?

 

 

Use the API key? It works once and then for some reason gets auto-revoked/forgotten by Emby. serversecurity.html shows an empty API list and any subsequent request with the API key that was issued is rejected.

Edited by bpbenich
Link to comment
Share on other sites

bpbenich

Update: I just did the following in the described order. It appears with no restore, no plugins, etc, just a fresh install has the same behavior.

Created a fresh FreeNAS iocage 11.2-RELEASE-p2 jail.   Installed Emby using this method.   Created user "Guest" with a password.   Rebooted the jail.   Created an API Key.   Logged in via API using AuthenticationByName (Successfully).   Checked serversecurity.html (API key is gone and no longer listed).   Attempted to Login via AuthenticationByName again (This time unsuccessfully).   Exported Log File (Attached Below).

 

Update 2: I've tested every Emby with the above method from 3.4.1.33-beta to 3.6.0.2-beta (all versions with ...freenas_3.x.x.x_amd64.txz via 'pkg install'). All were on 11.2-Release jails. I did try one on 11.1-Release jail as well. All behaved the exact same way.

Log.txt

Edited by bpbenich
Link to comment
Share on other sites

Happy2Play

On my Windows system I have deleted and create a key for "MPC Remote" several times without issue.  

 

3.5.2.0

3.6.0.2 beta

 

I will do fresh installs tomorrow to see if is makes a difference.

Link to comment
Share on other sites

bpbenich

@@Luke @@Happy2Play Thank you both for your help. But it seems that I've been framing this issue incorrectly. After further tinkering, it appears that it is not an issue of normal use. Apparently Emby and Sonarr are working just fine together and API Keys are functioning as normal.

 

It appears that the issue is with the API handler and my basic API requests. My code/scripts worked and still work fine on my old 3.4.1.0 emby server. But for some reason on 3.4.1.33-beta to 3.6.0.2-beta (Tested thus far) my API requests produce this issue. That issue being when it runs, it actually wipes out all API keys. With my recent attempt, this actually seems to be a larger and more serious issue than I thought. When I do either of these request to emby, emby seems to have a soft crash. Whether or not I even provide a valid API key, emby invalidates all active sessions (all users get forcibly logged out, streams seem not to stop), wipes out all API keys, and possibly more, probably serious things I have yet to observe.

 

This is my PHP code. This is the only part where it sends a request to Emby. It's all very simple and runs successfully when it has a valid key. 

    $postdata = http_build_query(
      array(
        'Username' => $user_username,
        'Pw' => $user_password
      )
    );
    $opts = array('http' =>
      array(
        'method'  => 'POST',
        'timeout' => 3,
        'header'  => 'Content-Type: application/x-www-form-urlencoded',
        'content' => $postdata
      )
    );
    $context = stream_context_create($opts);
    $result_txt = file_get_contents('http://<LOCAL-IP>:8096/emby/Users/AuthenticateByName'.'?api_key='.$api_key, false, $context);
    #print $result_txt;

Same happens through Curl command in terminal:

curl --header "Content-Type: application/json" --request POST --data '{"Username":"<USERNAME>","Pw":"<PASSWORD>"}' https://<PUBLIC-DOMAIN-NAME>:8920/emby/Users/AuthenticateByName?api_key=<API-KEY>

Before: 

5b7edd0568eb0_Before.png

 

After: 

5b7edd29e73a5_After.png

Edited by bpbenich
Link to comment
Share on other sites

bpbenich

@@Luke Originally I didn't have the API key attached to the request. But I kept getting this response without it: 

* upload completely sent off: 33 out of 33 bytes
< HTTP/1.1 400 Bad Request
< Content-Type: text/html
< Server: Microsoft-NetCore/2.0
< Date: Thu, 23 Aug 2018 17:49:26 GMT
< Content-Length: 45
< Connection: Close
< 
Value cannot be null.

And with it attached I get a successful response. But even if it worked without it, and I'm doing it wrong attaching it, it shouldn't be crashing Emby. Right now this could be used in an attack against a public facing Emby server.

Edited by bpbenich
Link to comment
Share on other sites

i tested and wasn't able to reproduce any crash. Nonetheless i would remove the param and then we can see why you can't authenticate. thanks.

Link to comment
Share on other sites

bpbenich

i tested and wasn't able to reproduce any crash. Nonetheless i would remove the param and then we can see why you can't authenticate. thanks.

 

 

If you see anything wrong with the curl command, I appreciate any comments:

curl --header "Content-Type: application/json" --request POST --data '{"Username":"Guest","Pw":"<PASSWORD>"}' https://<PUBLIC-DOMAIN>:8920/emby/Users/AuthenticateByName

It gives the above error. "Value cannot be null."

Edited by bpbenich
Link to comment
Share on other sites

bpbenich

did you try comparing to the request the web app is making?

 

 

I'd love to look over other example code, but seems to be non-exsistant online. Maybe I'll start a blog like @@Swynol. Remember, I had this working. This was a previously solved issue. So the short answer is no, I haven't thus far. The code worked (AND STILL DOES, just also crashes emby), so something had to have changed on Emby. (Which is perfectly fine; encouraged even)

Before when I was learning the API I had looked over the user service of Emby. This time I'm seeing "Password" is required (Of which I can only assume is a SHA1 of the password because of this. But now I get "Exception of type 'SQLitePCL.pretty.SQLiteException' was thrown.". 

And I might look over Sonarr's source code now that I need to get this working again. I could even spin up a CLI packet capture to examine a request.

Edited by bpbenich
Link to comment
Share on other sites

bpbenich

Here's a log file. This is with a fresh install of 3.5.2.0. I also added screenshot of running three different versions of my curl command. (Keep in mind I had to create a new API key for each because they were wiped out after each run.
 
5b7f1d36b4681_Screenshot.png

 

 

Log.txt

Edited by bpbenich
Link to comment
Share on other sites

I see this in the log for each authenticate request:

2018-08-23 13:27:22.599 Error HttpServer: Invalid username or password entered.

Are you sure those are correct?

Link to comment
Share on other sites

bpbenich

I see this in the log for each authenticate request:

2018-08-23 13:27:22.599 Error HttpServer: Invalid username or password entered.

Are you sure those are correct?

 

 

Yea, I had just reset and set the password before doing it, just to be sure. But you are probably seeing previous attempts where I accidentally used the command from my actual server where the username and password are different.

It's the last three attempts that are screenshot above.

Link to comment
Share on other sites

No that's still accurate. You need those headers when logging in, although not userid obviously because you don't have one yet.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...