Inloggegevens voor HTTP-basisverificatie worden opgeslagen totdat de browser wordt gesloten, maar is er een manier om de inloggegevens te verwijderen voordat de browser wordt gesloten?
Ik heb gelezen over een truc met HTTP 401-statuscode, maar het lijkt niet goed te werken(zie commentaar om te antwoorden). Misschien is het mechanisme dat trac gebruikt de oplossing.
Kunnen de inloggegevens worden verwijderd met JavaScript? Of met een combinatie van JavaScript en de status 401-truc?
Antwoord 1, autoriteit 100%
Update: deze oplossing lijkt in veel browsers niet meer te werken. Commentaar van Kaitsu:
Deze oplossing voor het verzenden van valse inloggegevens om de browser de juiste geverifieerde inloggegevens te laten vergeten, werkt niet in Chrome (16) en IE (9). Werkt in Firefox (9).
In feite kunt u een tijdelijke oplossing implementeren door valse referenties naar de service te sturen. Dit werkt in Browsers door een andere (niet-bestaande?) Gebruikersnaam zonder wachtwoord te verzenden. De browser verliest de informatie over de geverifieerde inloggegevens.
Voorbeeld:
https://www.example.com/=> Log in
met basisverificatie als “gebruiker1”Nu openen
Je bent uitgelogd. 😉
Met vriendelijke groeten
P.s.: Maar test dit alstublieft met alle benodigde browsers voordat u op de gegeven informatie vertrouwt.
Antwoord 2, autoriteit 28%
Uitbreiding van het antwoord van Jan. en bijwerken van het antwoord van owyongsk:
Hier is een voorbeeld van een jQuery java-scriptcode die ervoor zorgt dat de browser in wezen een nep-aanmeldingsverzoek stuurt naar de pagina die u probeert te beschermen, waardoor in alle geteste browsers de in het cachegeheugen opgeslagen inloggegevens werden verwijderd, waarna de gebruiker wordt omgeleid naar een niet-beveiligde pagina.
De waarschuwing() wanneer er iets misgaat, moet waarschijnlijk worden gewijzigd in iets anders.
//Submits an invalid authentication header, causing the user to be 'logged out'
function logout() {
$.ajax({
type: "GET",
url: "PUT_YOUR_PROTECTED_URL_HERE",
dataType: 'json',
async: true,
username: "some_username_that_doesn't_exist",
password: "any_stupid_password",
data: '{ "comment" }'
})
//In our case, we WANT to get access denied, so a success would be a failure.
.done(function(){
alert('Error!')
})
//Likewise, a failure *usually* means we succeeded.
//set window.location to redirect the user to wherever you want them to go
.fail(function(){
window.location = "/";
});
}
Toen was het net zo eenvoudig als de uitloglink de functie uitloggen() laten aanroepen, en het leek naadloos te werken voor de gebruiker, hoewel het technisch gezien nog steeds een hackklus is.
Antwoord 3, autoriteit 19%
Je kunt een hack proberen die momenteel werkt met de nieuwste Chrome en Firefox. Maak een “/logout”-pagina op uw server die alleen bepaalde referenties accepteert, zoals gebruikersnaam: false, wachtwoord: false. Met dit AJAX-verzoek hieronder kun je de gebruiker naar die pagina sturen.
$("#logout").click(function(e){
e.preventDefault();
var request = new XMLHttpRequest();
request.open("get", "/logout", false, "false", "false");
request.send();
window.location.replace("WHEREVER YOU WANT YOUR LOGGED OUT USER TO GO");
});
Wat gebeurt er is dat de valse gebruikersnaam en -wachtwoord in de cache van de geldige XMLHTTPREQUEST is in plaats van de inloggegevens van de huidige gebruiker, en wanneer een gebruiker probeert in te loggen op een willekeurige pagina, zal deze de fake-inloggegevens in de cache gebruiken, niet-bevoegd om te authenticeren Vraag de gebruiker om een andere in te voeren. Ik hoop dat dit helpt!
4, Autoriteit 11%
Eindelijk een implementatie afmaken die goed werkte voor mij:
Op de server evalueer ik de sessie, de gebruikersnaam en het wachtwoord, dus houd ik die informatie bij, de inlog-algoritm is als volgt:
1. Controleer of gebruiker en wachtwoord niet leeg is, anders retourneren 401.
2.Controleer of we de sessie in onze ingelogde gebruikerslijst hebben geregistreerd, indien niet, controleer dan of de gebruiker en het wachtwoord geldig is en zo ja opslaan Session ID in onze lijst, en vervolgens 401 retourneren.
Ik zal deze stap uitleggen: als de sessie-ID anders is, gebeurde een van de drie dingen:
a) de gebruiker opent een ander venster.
b) De gebruikerssessie is voltooid, dwz gebruiker uitgelogd.
c) de sessie verlopen vanwege inactiviteit.
Maar we willen de sessie opslaan zolang de gebruikersreferenties geldig zijn maar een 401 retourneren om een keer voor het wachtwoord te stellen, als we de sessie niet opslaan, kan de gebruiker nooit inloggen omdat we de nieuwe sessie-ID niet hebben in onze lijst.
3. Controleer of gebruikersreferenties gelijk hebben, zo ja, sessie-info opslaan en doorgaan met het serveren van pagina’s, anders retourneren 401.
Dus, het enige dat ik moet inloggen, is om de sessie op de server te sluiten wanneer de gebruiker de log-outpagina aanvraagt en de webbrowser opnieuw wordt weergegeven in het inlogdialoogvenster.
Ik denk aangezien ik dit schrijft dat er een stap moet zijn waar het programma controleert of de gebruiker al is ingelogd om onpersoonlijk te voorkomen, misschien kan ik meer dan één sessie-ID per gebruiker opslaan om meerdere sessie, nou ja, Ik wil graag uw opmerkingen over.
Ik hoop dat je het idee krijgt en commentaar als je een beveiligingsfout ziet;)
5, Autoriteit 8%
Als u controle hebt over de servercode, kunt u een “logout” -functie maken die “401 ongeoorloofd” antwoorden, ongeacht de gegeven inloggegevens. Deze falen dwingt browsers om opgeslagen inloggegevens te verwijderen.
Ik heb dit net getest met Chrome 34, IE 11, Firefox 25 – met Express.js Server en HTTP Basic-authenticatie.
Antwoord 6
Markeer de nonce als ongeldig. Ik heb een Ajax-oproep gedaan naar de server met de vraag om uit te loggen. De serverzijde krijgt het verzoek “Authenticeren: Digest…” in een header. Het extraheert de nonce=”” uit die regel en voegt deze toe aan een lijst met uitgeschakelde nonces. Dus de volgende keer dat de browser dat een verzoek stuurt met die regel “Authenticeren: Digest…”, antwoordt de server met 401. Hierdoor vraagt de browser de gebruiker om een nieuw gebruikers-ID/wachtwoord.
Werkt prima voor mijn applicatie, maar alleen voor Digest-authenticatie.