@David, der Autor des PR hat auf meinen Kommentar geantwortet, was ist deine Meinung dazu?:
Ich:
Dieser PR scheint das Problem mit dem fehlenden Namen und der fehlenden E-Mail-Adresse zu lösen?
PR-Autor:
Nein, leider nicht. Apple muss einen REST-API-Endpunkt bereitstellen, um Name/E-Mail abzurufen, da sie diese Informationen derzeit nur bei einer erfolgreichen Authentifizierung einmal übergeben und nicht bei nachfolgenden Authentifizierungen.
Ist ein einmaliger Abruf bei der ersten Autorisierung für uns nicht ausreichend?
Gibt es derzeit eine funktionierende Implementierung der „Anmelden mit Apple“-Funktion? Eine Website, an der ich als Marktplatzmitarbeiter arbeite, plant eine iOS-App. Ohne diese Option können wir keine anderen Authentifizierungsoptionen aktivieren, es sei denn, wir wollen riskieren, dass unsere App wegen Verstoßes gegen die App-Richtlinien abgelehnt wird.
Fühlen Sie sich frei, das Plugin zum Testen zu installieren, aber mir ist nicht bekannt, dass dies bereits behoben ist. Ich würde jedoch nicht empfehlen, es in der Produktion zu verwenden, bis es fertiggestellt oder zumindest von einem Entwickler, der sich Zeit nimmt, die Dinge zu bestätigen, freigegeben wurde.
Ich bin ein großer Befürworter dieses Features. Ich würde es gerne sehen, wenn es wie die anderen Anmeldeoptionen direkt in Discourse integriert wird.
Ich denke, dass man diese Art von Informationen absichtlich nicht abrufen kann.
Die Anzeige einer „Mit Apple anmelden"-Schaltfläche in deiner App oder auf deiner Website bedeutet, dass sich Benutzer mit nur einem Tippen über ihre bereits vorhandene Apple-ID anmelden oder registrieren können. Sie müssen keine Formulare ausfüllen, E-Mail-Adressen verifizieren oder Passwörter wählen. „Mit Apple anmelden" bietet eine neue, datenschutzfreundlichere Möglichkeit, sich einfach und schnell in Apps und auf Websites anzumelden. Gleichzeitig erhalten Benutzer ein konsistentes und vertrauenswürdiges Anmeldeerlebnis sowie den Komfort, nicht mehrere Konten und Passwörter merken zu müssen. In Fällen, in denen du nach Namen und E-Mail-Adresse fragst, haben Benutzer die Möglichkeit, ihre E-Mail-Adresse privat zu halten und stattdessen eine eindeutige, zufällige E-Mail-Adresse zu teilen.
Du hast recht, Datenschutz ist einer der wichtigsten Aspekte von „Mit Apple anmelden“, aber der entscheidende Teil deines Zitats ist:
Unter der Annahme, dass Nutzer uns ihren Namen und ihre E-Mail-Adresse zur Verfügung stellen, würden wir erwarten, diese bei jeder Anmeldung vom Anbieter zu erhalten. In der aktuellen Implementierung geschieht dies jedoch nicht. Nach der ersten Authentifizierung erhalten wir keine Benutzerinformationen mehr.
Ich denke nicht, dass dies etwas ist, das der Autor des Gems beheben kann – das müsste Apple ändern. Ich sehe nicht, dass dies in absehbarer Zeit passieren wird, also müssen wir Nutzer vielleicht bitten, ihren Namen und ihre E-Mail-Adresse manuell in Discourse einzugeben
Ich habe einen Fork von Robert/merefields Plugin teilweise zum Laufen gebracht (der Fork beinhaltet nur den Wechsel zu einer Kopie des omniauth-Gems, das ich aus der neuesten Quelle auf GitHub erstellt habe). Allerdings musste ich auf meinem Test-Discourse (der über ngrok Ende-zu-Ende HTTPS verwendet) die Site-Einstellung für Site-Cookies auf (keine) setzen, damit die Authentifizierung funktioniert. Mit dieser Einstellung deaktiviert kann ich ein Konto erstellen (selbst wenn das Anmeldeformular geschlossen war) und mich erneut anmelden. Wenn die Einstellung jedoch aktiviert ist, ist dies nicht möglich.
Der Backtrace eines fehlgeschlagenen Anmeldeversuchs ist unten aufgeführt:
Hat jemand hier Vorschläge, wie ich das Plugin so umschreiben kann, dass die Deaktivierung dieser Site-Einstellung für die Kernfunktionen nicht mehr erforderlich ist? Mein Plugin-Code befindet sich unter https://github.com/sau226dev/discourse-sign-in-with-apple, und der neueste Code, den ich für den Neuaufbau des omniauth-Gems verwendet habe, sollte sich in derselben GitHub-Organisation befinden.
Vielen Dank für jede Hilfe, die Sie im Voraus leisten können,
Das Plugin funktionierte ursprünglich bis zu einem gewissen Grad, wurde aber in letzter Zeit nicht weiter betreut, da das von David oben beschriebene Problem besteht.
Bis wir positive Nachrichten erhalten, dass Apple diesen fundamentalen Engpass behoben hat (das Senden von Name und E-Mail bei jedem Login-Versuch), lohnt es sich meiner Meinung nach nicht, diesen Code zu warten. Ich glaube nicht, dass es eine Möglichkeit gibt, dies zu umgehen. Deshalb habe ich nicht einmal versucht, die Abhängigkeiten zu aktualisieren. Das Plugin würde in jedem Fall beim Testen scheitern.
@orenwolf Es (das Fehlen von zurückgegebenem E-Mail-Namen/Name bei nachfolgenden Anmeldungen) schien kein Problem zu sein. Ich glaube, ich konnte das Anmeldefenster schließen und die Registrierung mit den korrekten übergebenen Daten fortsetzen. Wie bereits erwähnt, konnte ich im Anschluss sofort problemlos mit Apple anmelden.
Das einzige Problem, dem ich begegnet bin, war der CSRF-Fehler, es sei denn, die oben erwähnte Site-Einstellung wurde deaktiviert. Ein potenzielles Problem ist das Fehlen eines Namens im Anmeldeformular und dass der Benutzername das vor dem @-Zeichen in der E-Mail-Adresse steht (obwohl meiner Meinung nach diese potenziellen Probleme entweder kein Problem darstellen oder vom Benutzer leicht behoben werden können).
Zusätzlich zu Davids Kommentaren oben habe ich ein verwandtes Thema auf der Apple-Entwickler-Supportseite gefunden, das eine offizielle Antwort erhalten hat, die das Problem bestätigt:
Offizielle Antwort:
Hallo aslkdjalksdjasdasd,
Dies verhält sich korrekt. Benutzerinformationen werden nur bei der ersten Anmeldung des Benutzers in der ASAuthorizationAppleIDCredential übermittelt. Bei nachfolgenden Anmeldungen in Ihrer App mit „Anmelden mit Apple
Ich habe einen Pull Request erstellt, um das Omniauth-Apple-Gem auf die neueste Version zu aktualisieren. Diese Version enthält diesen Commit, der das Problem lösen könnte, dass bei jedem Login nicht die E-Mail-Adresse des Nutzers empfangen wird.
Um dies auszuprobieren, habe ich den empfohlenen Blogbeitrag befolgt, um die Zugangsdaten einzurichten. Allerdings bin ich bei zwei Punkten bisher nicht weitergekommen:
Wie lautet der Pfad für die Weiterleitungs-URL, die erforderlich ist, um die Service-ID bei Apple einzurichten?
Normalerweise reicht man einen PR ein, nachdem man etwas erfolgreich getestet hat
Bitte bestätige es, sobald du das getan hast.
Es scheint zwar eine Selbstverständlichkeit zu sein, aber ich wäre eher ermutigt, wenn wir eine Aussage von Apple hätten, dass sie nun jedes Mal eine E-Mail senden. Die Änderung der Gem-Version wird das Problem nicht lösen, wenn Apple das Kernproblem nicht behoben hat.
Ich werde mein Setup prüfen, wenn ich mich wieder als Apple-Entwickler registriere – das habe ich noch nicht getan … (dieser Eklat war ehrlich gesagt etwas entmutigend)
Ich habe versucht, unseren Fork des Plugins auf die neueste Version von omniauth-apple zu aktualisieren. (Beachte, dass dafür weitere Änderungen erforderlich sind, nicht nur eine Versionsnummer-Erhöhung).
tl;dr: Es funktioniert immer noch nicht.
Ich habe es in meiner Sandbox durch Hacken zum Laufen gebracht, aber es gibt immer noch mehrere Probleme:
Apple verwendet bei der Rückrufaktion (Callback) eine POST-Anfrage. Das ist bei OAuth-Implementierungen unüblich, da dies bedeutet, dass Cookies mit samesite=Lax nicht mit der Anfrage gesendet werden. Das führt dazu, dass Discourse die Sitzungs-Cookies während des Callbacks nicht lesen kann und daher einen CSRF-Fehler wirft.
UNSICHERE Workaround-Lösung: Deaktivieren dieser Sicherheit, indem die Discourse-Cookies auf samesite=None gesetzt werden.
Die Verwendung einer POST-Anfrage ohne CSRF-Token löst eine weitere Sicherheitsmaßnahme im Kern von Discourse aus.
UNSICHERE Workaround-Lösung: Entfernen dieser Zeile.
Ich erhielt von Apple eine 403-Fehlermeldung, als das omniauth-Gem die JWKs abrufte. Ich vermute, dass der Accept:-Header nicht korrekt gesetzt wird, habe das aber noch nicht überprüft.
UNSICHERE Workaround-Lösung: Die Schlüssel manuell fest codieren.
Nach all dem konnte ich mich schließlich mit Apple anmelden. Du kannst es auf https://sandbox.dtaylor.uk ausprobieren (ich lasse es einige Tage funktionieren, aber bitte gib dort keine sensiblen Daten ein, da es UNSICHER ist).
Und dann… E-Mails und Namen werden nur beim ersten Authentifizierungsvorgang übermittelt. Du kannst das testen: Melde dich mit Apple an, brich die Kontoeinrichtung ab und versuche es erneut. Beim zweiten Versuch fehlen deine Daten.
Angenommen, Apple wird die Dinge in absehbarer Zeit nicht ändern… wie könnten wir das zum Laufen bringen?
Für (1) und (2) könnten wir das POST von Apple in ein GET umwandeln, ohne die Sicherheit zu beeinträchtigen. Wenn wir eine POST-Anfrage beim Callback erhalten, rendern wir etwas JavaScript, das window.location='/auth/apple/callback?code=...&state=...' setzt. Von dort aus würde es genau wie bei jedem anderen Anbieter funktionieren. Allerdings würde das Abfangen der POST-Anfrage wahrscheinlich einige Änderungen an der Kern-API erfordern.
Für (3) könnte das Problem wahrscheinlich mit etwas Arbeit am omniauth-Gem behoben werden.
Aber wir stecken immer noch ohne Namen/E-Mail fest, daher bin ich mir nicht sicher, ob es sich lohnt, diese anderen Probleme zu beheben
Vielen Dank, dass du es noch einmal versucht und deine Analyse geteilt hast! Vielleicht könnte die Einreichung eines technischen Support-Tickets bei Apple Licht auf die verbleibenden Probleme werfen? Aus meiner Erfahrung ist es dort wahrscheinlicher, dass sie mögliche Lösungen oder Workarounds anbieten als in den Apple-Entwicklerforen.
