Vraag Kun je de gebruiker / pass voor HTTP-basisverificatie in URL-parameters doorgeven?


Ik geloof dat dit niet mogelijk is, maar iemand die ik ken, stond erop dat het werkt. Ik weet niet eens welke parameters ik moet proberen, en ik heb dit nergens gedocumenteerd gevonden.

ik probeerde http://myserver.com/~user=username&password=mypassword maar het werkt niet.

Kunt u bevestigen dat het niet mogelijk is om de gebruiker / pass via HTTP-parameters (GET of POST) door te geven?


124
2018-03-21 11:16


oorsprong


gebruiker: pass@example.com - Smudge
@sam - wat? Hoe zou de volledige URL er uitzien? - ripper234
Allemaal in de spec ietf.org/rfc/rfc1738.txt (3.1) - Smudge
@sam - Sorry, ik heb je reactie om de een of andere reden niet kunnen verwerken. - ripper234


antwoorden:


Het is inderdaad niet mogelijk om de gebruikersnaam en het wachtwoord via queryparameters door te geven in standaard HTTP-authenticatie. In plaats daarvan gebruikt u een speciale URL-indeling, zoals deze: http://username:password@example.com/ - dit verzendt de referenties in de standaard HTTP "Autorisatie" -kop.

Het is mogelijk dat degene met wie u sprak, dacht aan een aangepaste module of code die naar de queryparameters keek en de referenties verifieerde. Dit is geen standaard HTTP-authenticatie, maar het is een applicatie-specifiek iets.


167
2018-03-21 11:38



Bedankt, dit is precies wat ik zocht ... het is niet essentieel dat het GET-parameters zijn, alleen dat ik het in de URL kan verwerken. - ripper234
Ter info, de http://username:password@example.com indeling wordt niet langer door beide ondersteund D.W.Z of Chrome, zou niet verbaasd zijn als anderen volgden als ze dat nog niet hadden gedaan. - T.J. Crowder
Eigenlijk werkt het prima in Chrome. Alleen IE is een verwend nest. - Damien Overeem ツ
@DamienOver welke Chrome-versie beschik je? ik ben op Mac OS X 37 en het lijkt niet voor mij te werken - Chris DaMour
Ik heb sindsdien geleerd dat Chrome de app een tijdje heeft uitgeschakeld, maar heeft deze functie later opnieuw ingeschakeld. Ik heb ook geleerd dat Safari phishing-fouten zal veroorzaken bij het tegenkomen van dit soort koppelingen. Kortom, de tijd van url-gebaseerde http-authenticatie is voorbij .. - Damien Overeem ツ


http: // gebruikersnaam: password@example.com zal werken voor FireFox, Chrome, Safari MAAR niet voor IE.

Microsoft Knowledge Base


16
2018-01-23 10:50



Deze mogelijkheid is verwijderd uit Chrome 19+. Zien code.google.com/p/chromium/issues/detail?id=123150 - Moshe Katz
Door het lezen van dat bugrapport werd het teruggeplaatst in Chrome 20. Zeker, ik zou verwachten dat veel van het blijven klagen als dit niet het geval was geweest. - womble♦
Ik heb het nu aangevraagd voor Internet Explorer: connect.microsoft.com/IE/feedback/details/873575/.... Enigszins verschillende use-case, maar behandelt hetzelfde probleem;) - SimonSimCity
@Diago als het wachtwoord '@' bevat, werkt het niet. het geeft een fatale fout, kan iemand me vertellen hoe we gebruikersnaam en wachtwoord in een keer kunnen geven - Ashish Jain
@AshishJain - Ik zou proberen te ontsnappen aan de @ in het wachtwoord als %40. (Ik weet echter niet of dat werkt, en het kan afhangen van de combinatie van server of browser / server.) - David Moles


Het doorgeven van basisverificatieparameters in URL is niet aanbevolen

Er is een Autorisatie-headerveld om dit hier te controleren: http-koplijst

Hoe het te gebruiken is hier geschreven: Basis toegang authenticatie

Daar kun je ook lezen dat hoewel het nog steeds door sommige browsers wordt ondersteund, de voorgestelde oplossing voor het toevoegen van de basis autorisatiegegevens in de URL niet wordt aanbevolen.

Lees ook hoofdstuk 4.1 in RFC 2617 - HTTP-verificatie voor meer informatie over waarom GEEN basisverificatie gebruiken.


Authenticatieparameters doorgeven in queryreeks

Wanneer u OAuth of andere authenticatieservices gebruikt, kunt u vaak ook uw toegangstoken verzenden in een querytekenreeks in plaats van in een autorisatiekop, dus bijvoorbeeld:

GET https://www.example.com/api/v1/users/1?access_token=1234567890abcdefghijklmnopqrstuvwxyzABCD

14
2017-09-24 07:55



En hoe gaat het om het coderen van een Autorisatie-header in een URL? - womble♦
Is dat niet het formulier dat u hebt opgegeven, is nu verouderd? - womble♦
De vraag die u hebt beantwoord met "Er is een autorisatiekopveld voor dit doel", vroeg hoe u authenticatieparameters kunt instellen in de URL. Als u HTTP-headervelden niet in een URL kunt coderen (wat u niet kunt), is uw antwoord een non-sequitur. - womble♦
Kun je aangeven waar in de URI-standaard staat dat het doorgeven van basisverificatieparameters in de URI is verouderd? RFC 2396 zegt alleen dat het "NIET AANBEVOLEN" is, omdat authenticatiedetails in platte tekst in veel gevallen geen goed idee zijn (waar ik het mee eens ben), terwijl RFC 7235 niets vermeldt. Nergens in de specs kan ik zoeken zegt dat het verouderd is. - Lie Ryan
@Wilt: ik moet me verontschuldigen, je hebt inderdaad gelijk. Uw hint dat de specificatie "gewijzigd" was, zette mij aan tot verder onderzoek (een RFC wordt nooit gewijzigd nadat het is gepubliceerd / genummerd). Ik heb net geconstateerd dat RFC 2396 feitelijk is achterhaald door RFC 3986, die ik eerder niet kon vinden. RFC 3986 vermeldt de verwerping van gebruikersnaam: wachtwoordsyntaxis: Use of the format "user:password" in the userinfo field is deprecated. - Lie Ryan


Het is (uiteraard) mogelijk om elke tekenreeks in de GET-parameters te verzenden, hoewel het niet wordt aanbevolen om aanmeldingsgegevens en wachtwoorden te verzenden, waardoor deze zeer goed zichtbaar kunnen worden, vooral als deze niet in een AJAX-verzoek staan.

U moet de serverpagina echter coderen om de login en het wachtwoord uit te pakken en deze vervolgens valideren en gebruiken op elke gewenste manier.


0
2017-09-11 08:22