Discussion API and Powershell - Questions

[PPrime]

Hi All,

Have made some progess in getting the API to work in PowerShell, but I don't seem to be able to get the confirmation part to work. I think it might be my Cookies but since PowerShell takes care of that in web sessions I cannot figure out what I am doing wrong.

What I have so far working:

$uriLogin = "https://companion.orerve.net/user/login"
$uriConfirm = "https://companion.orerve.net/user/confirm"
$uriProfile = "https://companion.orerve.net/profile"
$ua = "Mozilla/5.0 (iPhone; CPU iPhone OS 7_1_2 like Mac OS X) AppleWebKit/537.51.2 (KHTML, like Gecko) Mobile/11D257"
$postParams = @{email='email@address.com';password='password'}
$wrLogin = invoke-webrequest -uri $uriLogin -useragent $ua -SessionVariable orerve -method post -body $postParams

From here, $wrLogin.BaseResponse indicates I need to confirm, and I'm getting the confirmation email with a code, so from there I do

$code = @{code='ABCDE'}
$wrConfirm = Invoke-WebRequest -uri $uriConfirm -UserAgent $ua -WebSession $orerve -Method Post -Body $code

The $wrConfirm.BaseResponse indicates I am still on the Confirm page - I have not been redirected back to the login page.
My cookiejar in $orerve still has a domain session cookie as well.
I have no reason not to believe this has not worked, but also no real way to confirm

Then I try

$wrProfile = Invoke-webrequest -uri $uriProfile -userAgent $ua -websession $orerve -method Get

My base response now seems to indicate that I have been redirected back to the Login page, and I have no JSON data. So the API does not think I have logged in. So either I'm not doing something right on the confirm page, or my WebSession is not working as it should be.

If anyone is able to help I'd appreciate it

 

[wolverine2710]

Hi All,

Have made some progess in getting the API to work in PowerShell, but I don't seem to be able to get the confirmation part to work. I think it might be my Cookies but since PowerShell takes care of that in web sessions I cannot figure out what I am doing wrong.

What I have so far working:

$uriLogin = "https://companion.orerve.net/user/login"
$uriConfirm = "https://companion.orerve.net/user/confirm"
$uriProfile = "https://companion.orerve.net/profile"
$ua = "Mozilla/5.0 (iPhone; CPU iPhone OS 7_1_2 like Mac OS X) AppleWebKit/537.51.2 (KHTML, like Gecko) Mobile/11D257"
$postParams = @{email='email@address.com';password='password'}
$wrLogin = invoke-webrequest -uri $uriLogin -useragent $ua -websession orerve -method post -body $postParams

From here, $wrLogin.BaseResponse indicates I need to confirm, and I'm getting the confirmation email with a code, so from there I do

$code = @{code='ABCDE'}
$wrConfirm = Invoke-WebRequest -uri $uriConfirm -UserAgent $ua -WebSession $orerve -Method Post -Body $code

The $wrConfirm.BaseResponse indicates I am still on the Confirm page - I have not been redirected back to the login page.
My cookiejar in $orerve still has a domain session cookie as well.
I have no reason not to believe this has not worked, but also no real way to confirm

Then I try

$wrProfile = Invoke-webrequest -uri $uriProfile -userAgent $ua -websession $orerve -method Get

My base response now seems to indicate that I have been redirected back to the Login page, and I have no JSON data. So the API does not think I have logged in. So either I'm not doing something right on the confirm page, or my WebSession is not working as it should be.

If anyone is able to help I'd appreciate it

I don't have power shell knowledge, more of a Linux man. If you want to be able to access the API from the prompt you could have a look at the thread "Accessing the API using Curl". It uses curl as a command line tool - for making a http request. Curl is also available for windows. You could run curl from your powershel script.l. Also does the api work for you with tools like EDMC etc?

I still hope that you get it working as a pure powershell solution, would be cool. I'm hoping others can help your further with a 100% pure PS solution.

 

[PPrime]

Bit more information.

I did the whole End-To-End Process using a Chrome and the Dev-Tools for emulation (I set it as an iPhone 5).

Captured the headers along the way

Noticed that I was getting quite a few more Cookies than my PS WebSession was saving. In fact, it only really seemed to save the 'CompanionApp' cookie, and not the 'mid' cookie, which it gets with the confirm page request

I also seem to be unable to retrieve any of the 'set-cookie' headers manually out of the response. In fact my response is missing quite a few items, so I can't create it manually either. Bummer.

This seems to only be a problem with this web service as well, which is odd.. I sent a test to google and I get the 'set-cookie' part of the header in my response.

I'll keep chipping away but I'm fast approaching the too-hard-basket

 

[wolverine2710]

Bit more information.

I did the whole End-To-End Process using a Chrome and the Dev-Tools for emulation (I set it as an iPhone 5).

Captured the headers along the way

Noticed that I was getting quite a few more Cookies than my PS WebSession was saving. In fact, it only really seemed to save the 'CompanionApp' cookie, and not the 'mid' cookie, which it gets with the confirm page request

I also seem to be unable to retrieve any of the 'set-cookie' headers manually out of the response. In fact my response is missing quite a few items, so I can't create it manually either. Bummer.

This seems to only be a problem with this web service as well, which is odd.. I sent a test to google and I get the 'set-cookie' part of the header in my response.

I'll keep chipping away but I'm fast approaching the too-hard-basket

I've created a post for you in the EDDN thread, see here.
Fingers crossed.

 

[Otis B.]

$code = @{code='ABCDE'}
$wrConfirm = Invoke-WebRequest -uri $uriConfirm -UserAgent $ua -WebSession $orerve -Method Post -Body $code

The $wrConfirm.BaseResponse indicates I am still on the Confirm page - I have not been redirected back to the login page.

This means that verification failed. If it had succeeded you would have been redirected away from the Confirm page.

I've never used PowerShell but from a quick look at the docs I think in your first login call you should use -SessionVariable instead of -WebSession to create the session variable which will hold the "CompanionApp" session cookie.

Also, you should find a way to preserve the "mid" and "mtk" persistant cookies that the server sets after successful verification so that you don't have to verify every time. Edit: This might give you some pointers.

 

[PPrime]

This means that verification failed. If it had succeeded you would have been redirected away from the Confirm page.


I've never used PowerShell but from a quick look at the docs I think in your first login call you should use -SessionVariable instead of -WebSession to create the session variable which will hold the "CompanionApp" session cookie.


Also, you should find a way to preserve the "mid" and "mtk" persistant cookies that the server sets after successful verification so that you don't have to verify every time. Edit: This might give you some pointers.

Actually I had -sessionVariable in my own script, I must have accidentally altered it during copy/paste when I changed the PostParams :/. Thanks for catching it though.


Also. The issue seems to be either the Invoke-WebRequest cmdlet not capturing all the headers, or more likely, not saving all the headers to the websession. Since I'm not able to view all the headers I cannot manually create them.


Thanks for the feedback guys. Appreciated.

 

[PPrime]

If you want to be able to access the API from the prompt you could have a look at the thread "Accessing the API using Curl". It uses curl as a command line tool - for making a http request.

Not a bad idea. As a work-around I have it calling a Python script and returning the json as a PSOBJECT.

Should also of mentioned Im using PowerShell 5.

As for CURL, thought this was funny. There is an in-built alias for CURL that just invokes the Invoke-WebRequest cmdlet. Well played, Microsoft. Maybe next time your cmdlet won't be bugged

PS ps:\> Get-Alias curl


CommandType     Name                                               Version    Source                                                                                       
-----------     ----                                               -------    ------                                                                                       
Alias           curl -> Invoke-WebRequest                                                                                                                                  






PS ps:\>

 

[wolverine2710]

@PPrime. Nice you have it working with a workaround. You might however be VERY interested in the following brand new EDCodex entry ( 2016-01-23 14:27:40): Elite Mission Reporter. Its open source, uses the iPhone api AND one of the screenshots strongly suggests it uses the MS power shell. This might be worth checking out ;-). Screenshot in the spoiler.

Spoiler

 

[jgm]

The issue is similar to one I saw with the C# library, in that due to the redirections some of the cookies go missing. The solution for this is twofold: firstly to not follow the redirection, and secondly to keep track of the cookies manually. Here is a complete example using PowerShell:

# We need a custom function to pull the cookies from the relevant HTTP header
function ConvertFrom-SetCookieHeader {
  [cmdletbinding()]
  Param
  (
    #Define parameters
    [Parameter(Mandatory=$true,Position=0)]
    [string] $SetCookieHeader
  )


  $session = New-Object Microsoft.PowerShell.Commands.WebRequestSession
  $SetCookieHeader = $SetCookieHeader.Replace('secure,', 'secure=1; ').Replace('secure;', 'secure=1;');
  $MatchInfo = Select-String -InputObject $SetCookieHeader "(.*?)=(.*?)($|;|,(?! ))" -AllMatches;
  foreach ($Match in $MatchInfo.Matches) {
    if (!$Match.Success) { continue; }
    if ($Match.Groups.Value[1].Trim() -eq "CompanionApp") {
      $sessionCookie = New-Object System.Net.Cookie
      $sessionCookie.Name = $Match.Groups.Value[1].Trim()
      $sessionCookie.Domain = "companion.orerve.net"
      $sessionCookie.Value = $Match.Groups.Value[2].Trim()
      $session.Cookies.Add($sessionCookie);
    }
    elseif ($Match.Groups.Value[1].Trim() -eq "mid" -or $Match.Groups.Value[1].Trim() -eq "mtk" ) {
      $sessionCookie = New-Object System.Net.Cookie
      $sessionCookie.Name = $Match.Groups.Value[1].Trim()
      $sessionCookie.Domain = ".companion.orerve.net"
      $sessionCookie.Value = $Match.Groups.Value[2].Trim()
      $session.Cookies.Add($sessionCookie);
    }
  }

  return $session;
}

$email = "your_email_here"
$password = "your_password_here"
$user_agent = "Mozilla/5.0 (iPhone; CPU iPhone OS 7_1_2 like Mac OS X) AppleWebKit/537.51.2 (KHTML, like Gecko) Mobile/11D257"

# Send the login request
$response = Invoke-WebRequest -Uri "https://companion.orerve.net/user/login" -MaximumRedirection 0 -ErrorAction Ignore -UserAgent "$user_agent" -UseBasicParsing -method post -body "email=$email&password=$password"

# Obtain the cookies
$session = ConvertFrom-SetCookieHeader($response.Headers.'set-cookie')

$code = "your_code_here"

# Send the confirmation request
$response = Invoke-WebRequest -Uri "https://companion.orerve.net/user/confirm" -Websession $session -MaximumRedirection 0 -ErrorAction Ignore -UserAgent "$user_agent" -UseBasicParsing -method post -body "code=$code"

# Update the cookies
$session = ConvertFrom-SetCookieHeader($response.Headers.'set-cookie')

# Send the profile request
$response = Invoke-WebRequest -Uri "https://companion.orerve.net/profile" -Websession $session -MaximumRedirection 0 -ErrorAction Ignore -UserAgent "$user_agent" -UseBasicParsing

# Update the cookies - if you don't do this after each request you might be asked to log in again
$session = ConvertFrom-SetCookieHeader($response.Headers.'set-cookie')

# Convert the JSON string to an object
$profile = $response.Content | ConvertFrom-Json

# Obtain the commander's name
$profile.commander.name

 

[PPrime]

The issue is similar to one I saw with the C# library, in that due to the redirections some of the cookies go missing. The solution for this is twofold: firstly to not follow the redirection, and secondly to keep track of the cookies manually. Here is a complete example using PowerShell:

Nice. I didn't even think of the redirection as being the problem, but that totally makes sense and explains why I was unable to manage the cookies manually. The frustrating part was that I knew it should be possible in native PowerShell, but couldn't figure out exactly where it was going wrong.

Thanks a ton.

Thanks Wolverine as well. Have some rep