Za pomocą cURL możemy przekazać nazwę użytkownika z żądaniem HTTP w następujący sposób:

$ curl -u <your_username> https://api.github.com/user

-uFlagi przyjmuje nazwę użytkownika do uwierzytelniania, a następnie cURL poprosi hasło. Przykład cURL dotyczy uwierzytelniania podstawowego za pomocą interfejsu API GitHub .

W jaki sposób podobnie przekazujemy nazwę użytkownika i hasło wraz z Invoke-WebRequest? Ostatecznym celem jest korzystanie z programu PowerShell z uwierzytelnianiem podstawowym w interfejsie API GitHub.

Zakładam tutaj uwierzytelnianie podstawowe.

$cred = Get-Credential
Invoke-WebRequest -Uri 'https://whatever' -Credential $cred

Możesz uzyskać swoje dane uwierzytelniające w inny sposób ( Import-Clixmlitp.), Ale musi to być [PSCredential]obiekt.

Edytuj na podstawie komentarzy:

GitHub łamie RFC, jak wyjaśniają w podanym przez Ciebie łączu :

Interfejs API obsługuje uwierzytelnianie podstawowe zdefiniowane w dokumencie RFC2617 z kilkoma niewielkimi różnicami. Główną różnicą jest to, że RFC wymaga odpowiedzi na nieuwierzytelnione żądania za pomocą 401 nieautoryzowanych odpowiedzi. W wielu miejscach ujawniłoby to istnienie danych użytkownika. Zamiast tego interfejs API GitHub odpowiada komunikatem 404 Not Found. Może to powodować problemy dla bibliotek HTTP, które zakładają odpowiedź nieautoryzowaną 401. Rozwiązaniem jest ręczne utworzenie nagłówka Authorization.

Według Invoke-WebRequestmojej wiedzy, PowerShell czeka na odpowiedź 401 przed wysłaniem poświadczeń, a ponieważ GitHub nigdy ich nie dostarcza, twoje poświadczenia nigdy nie zostaną wysłane.

Ręcznie utwórz nagłówki

Zamiast tego będziesz musiał samodzielnie utworzyć podstawowe nagłówki uwierzytelniania.

Uwierzytelnianie podstawowe pobiera ciąg składający się z nazwy użytkownika i hasła oddzielone dwukropkiem, user:passa następnie wysyła wynik zakodowany w formacie Base64.

Kod taki powinien działać:

$user = 'user'
$pass = 'pass'

$pair = "$($user):$($pass)"

$encodedCreds = [System.Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes($pair))

$basicAuthValue = "Basic $encodedCreds"

$Headers = @{
    Authorization = $basicAuthValue
}

Invoke-WebRequest -Uri 'https://whatever' -Headers $Headers

Możesz łączyć niektóre konkatenacje ciągów, ale chciałem to przerwać, aby było jaśniejsze.

Użyj tego:

$root = 'REST_SERVICE_URL'
$user = "user"
$pass= "password"
$secpasswd = ConvertTo-SecureString $pass -AsPlainText -Force
$credential = New-Object System.Management.Automation.PSCredential($user, $secpasswd)

$result = Invoke-RestMethod $root -Credential $credential

Musiałem to zrobić, aby zadziałało:

$pair = "$($user):$($pass)"
$encodedCredentials = [System.Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes($Pair))
$headers = @{ Authorization = "Basic $encodedCredentials" }
Invoke-WebRequest -Uri $url -Method Get -Headers $headers -OutFile Config.html

Invoke-WebRequestjest zgodny z RFC2617, jak zauważył @briantist, jednak istnieją pewne systemy (np. JFrog Artifactory), które pozwalają na anonimowe użycie, jeśli Authorizationnagłówek jest nieobecny, ale odpowiedzą, 401 Forbiddenjeśli nagłówek zawiera nieprawidłowe poświadczenia.

Można to wykorzystać do wyzwolenia 401 Forbidden odpowiedzi i zabrania się -Credentialsdo pracy.

$login = Get-Credential -Message "Enter Credentials for Artifactory"

                              #Basic foo:bar
$headers = @{ Authorization = "Basic Zm9vOmJhcg==" }  

Invoke-WebRequest -Credential $login -Headers $headers -Uri "..."

Spowoduje to wysłanie nieprawidłowego nagłówka za pierwszym razem, który zostanie zastąpiony prawidłowymi danymi uwierzytelniającymi w drugim żądaniu, ponieważ -Credentialszastępuje Authorizationnagłówek.

Przetestowano z Powershell 5.1

Gdyby ktoś potrzebował jednej wkładki:

iwr -Uri 'https://api.github.com/user' -Headers @{ Authorization = "Basic "+ [System.Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes("user:pass")) }

innym sposobem jest użycie certutil.exe, zapisz swoją nazwę użytkownika i hasło w pliku np. in.txt jako nazwa użytkownika: hasło

certutil -encode in.txt out.txt

Teraz powinieneś móc użyć wartości auth z out.txt

$headers = @{ Authorization = "Basic $((get-content out.txt)[1])" }
Invoke-WebRequest -Uri 'https://whatever' -Headers $Headers

Wiem, że jest to trochę odbiegające od pierwotnego żądania OP, ale natknąłem się na to, szukając sposobu na użycie Invoke-WebRequest przeciwko witrynie wymagającej podstawowego uwierzytelnienia.

Różnica polega na tym, że nie chciałem zapisywać hasła w skrypcie. Zamiast tego chciałem poprosić program uruchamiający skrypty o dane uwierzytelniające dla witryny.

Oto jak sobie z tym poradziłem

$creds = Get-Credential

$basicCreds = [pscredential]::new($Creds.UserName,$Creds.Password)

Invoke-WebRequest -Uri $URL -Credential $basicCreds

W rezultacie program uruchamiający skrypt jest monitowany o okno dialogowe logowania dla U / P, a następnie Invoke-WebRequest może uzyskać dostęp do witryny przy użyciu tych poświadczeń. To działa, ponieważ $ Cred.Password jest już zaszyfrowanym ciągiem.

Mam nadzieję, że pomoże to komuś szukającemu podobnego rozwiązania powyższego pytania, ale bez zapisywania nazwy użytkownika lub PW w skrypcie

To właśnie zadziałało w naszej szczególnej sytuacji.

Notatki pochodzą z Wikipedii na temat uwierzytelniania podstawowego po stronie klienta . Dziękuję @ briantist za pomoc!

Połącz nazwę użytkownika i hasło w jeden ciąg username:password

$user = "shaunluttin"
$pass = "super-strong-alpha-numeric-symbolic-long-password"
$pair = "${user}:${pass}"

Zakoduj ciąg zgodnie z wariantem RFC2045-MIME Base64, z wyjątkiem nie ograniczania się do 76 znaków / linii.

$bytes = [System.Text.Encoding]::ASCII.GetBytes($pair)
$base64 = [System.Convert]::ToBase64String($bytes)

Utwórz wartość Auth jako metodę, spację, a następnie zakodowaną parę Method Base64String

$basicAuthValue = "Basic $base64"

Utwórz nagłówek Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

$headers = @{ Authorization = $basicAuthValue }

Wywołaj żądanie sieciowe

Invoke-WebRequest -uri "https://api.github.com/user" -Headers $headers

Wersja tego programu PowerShell jest bardziej szczegółowa niż wersja cURL. Dlaczego? @briantist wskazał, że GitHub łamie RFC i PowerShell się do tego trzyma. Czy to oznacza, że ​​cURL również łamie standardy?