Home of the Squeezebox™ & Transporter® network music players.
Results 1 to 7 of 7
  1. #1
    Junior Member
    Join Date
    Jul 2017
    Posts
    5

    POST Login via SimpleAsyncHTTP

    Good evening,

    I am trying to connect with an internet service. This service requires authentication by sending a POST request to an endpoint expecting the result of a html form. I am trying to figure out how to create such request. My best (not working) guess was the following:
    Code:
    $user =  $self->{user};
    $pass =  $self->{pass};
    
    Slim::Networking::SimpleAsyncHTTP->new(
        sub
        {
           # success code
        },
        sub
        {
            # error code
        }
    )->post($request_url, "user[email]=$user&user[password]=$pass");
    If someone could help me I would be really happy. Are there any existing plugins that are also doing this kind of authentication?.

  2. #2
    Babelfish's Best Boy mherger's Avatar
    Join Date
    Apr 2005
    Location
    Switzerland
    Posts
    19,746

    POST Login via SimpleAsyncHTTP

    > If someone could help me I would be really happy. Are there any existing
    > plugins that are also doing this kind of authentication?.


    Looking about good to me. How does it fail? Check the error you get on
    the endpoint as well as in the error handler.

    You might need to escape the post body, or add a content type header.

    --

    Michael

  3. #3
    Junior Member
    Join Date
    Jul 2017
    Posts
    5
    I still can not get it to working. The $user and the $pass are url encoded and now I have added the correct "Content-Type" header. I have written a small python script to check if everything is submitted correctly. This script decodes everything as I do expect. Strange thing is I am now getting an 404 error. Even more strange is that running the following is actually working.
    Code:
    curl -X POST -d "user[email]=url_encoded_mail&user[password]=url_encoded_pass" https://play.pocketcasts.com/users/sign_in
    There is also a python lib available (https://github.com/exofudge/Pocket-Casts) that works perfectly fine. I have tried to intercept the traffic with mitmproxy (A tool that acts as a proxy and resigns every https request). Problem here is, that slimserver is not using the proxy for https requests. I tried to enable it by patching Slim::Networking::Async::HTTP @ line 114. Now slimserver tries to use a malformatted http proxy request. As this is my first contact with perl I did not want to dig deeper here before trying to get input on this topic from someone more experienced.
    My code for setting the parameters looks as follows:
    Code:
    my $user =  uri_escape($self->{user});
    my $pass =  uri_escape($self->{pass});
    my $post_data = "user[email]=$user&user[password]=$pass";
    The only idea I have left now is that slimserver is using an old cipher and that the server reacts by sending a 404.

  4. #4
    Babelfish's Best Boy mherger's Avatar
    Join Date
    Apr 2005
    Location
    Switzerland
    Posts
    19,746
    What does LMS' server.log say? 404 means you're not requesting the address you think you are. Maybe https is disable lack of IO::Socket::SSL? The server.log file has some plain text error messages in this case. That's much simpler to read than setting up a proxy to intercept encrypted traffic :-)
    Michael

    http://www.herger.net/slim-plugins - MusicArtistInfo, MusicInfoSCR

  5. #5
    Junior Member
    Join Date
    Jul 2017
    Posts
    5
    I found my solution. Long story short is that after a successful request the server sends a 302 redirection code to another URI. It expects it to be done via a GET request. Slimserver instead sends a POST request to the new target URI.

    Slimserver is behaving correctly here. The HTTP 1.0 specification clearly states that in response to a servers 302 status code, the client has to use the same request type again. If the server expects a GET request it should send a 303. This status code was introduced with HTTP 1.1. Many HTTP 1.0 clients at that time did not respect the specification at this point. The reason that I am describing this in such detail is the fact that most clients still do not do so. This comment in chromiums sourcecode explains this and also leads to this IETF document acknowledging the situation and permitting the client to switch over to a GET request after a POST request answered by a 302. I would suggest to change slimservers behaviour at this point as it would increase interoperability while still respecting the current specification.

  6. #6
    Babelfish's Best Boy mherger's Avatar
    Join Date
    Apr 2005
    Location
    Switzerland
    Posts
    19,746
    Quote Originally Posted by dazuag View Post
    I found my solution. Long story short is that after a successful request the server sends a 302 redirection code to another URI. It expects it to be done via a GET request. Slimserver instead sends a POST request to the new target URI.

    Slimserver is behaving correctly here. The HTTP 1.0 specification clearly states that in response to a servers 302 status code, the client has to use the same request type again. If the server expects a GET request it should send a 303. This status code was introduced with HTTP 1.1. Many HTTP 1.0 clients at that time did not respect the specification at this point. The reason that I am describing this in such detail is the fact that most clients still do not do so. This comment in chromiums sourcecode explains this and also leads to this IETF document acknowledging the situation and permitting the client to switch over to a GET request after a POST request answered by a 302. I would suggest to change slimservers behaviour at this point as it would increase interoperability while still respecting the current specification.
    Wow... good catch! Can you tell me what endpoint you're experiencing this issue with? Would I be able to re-produce this? Or could you share your code with me (privately if needed - PM me)?
    Michael

    http://www.herger.net/slim-plugins - MusicArtistInfo, MusicInfoSCR

  7. #7
    Junior Member
    Join Date
    Jul 2017
    Posts
    5
    Yes the endpoint is https://play.pocketcasts.com/users/sign_in. You are able to reproduce this by creating a POST request and let your server answer with 302 leading to an endpoint expecting a GET request. Now slimserver will send another POST request to the new endpoint. My code really does nothing else special that could influence this behavior. If it would still be helpful for you I could post it here but please be aware that my perl skills, as mentioned earlier, are quite "immature".

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •