Mit Apple anmelden

Wird ‘Mit Apple anmelden’ eine unterstützte Anmeldemethode sein, wenn es später in diesem Jahr allgemein verfügbar wird?

16 „Gefällt mir“

Noch wurde niemand damit beauftragt, aber ich vermute, dass dies passieren wird, sobald sie an Fahrt aufnehmen. Selbst wenn wir dies nicht schnell im Kern von Discourse umsetzen, ist es wahrscheinlich, dass jemand in der Community ein Plugin erstellt.

12 „Gefällt mir“

Cool. Ich hatte das noch nirgends erwähnt gesehen, also dachte ich, ich bringe es mal zur Sprache!

Ich könnte das gerne angehen, da ich gerade einen PR für das Discord-Plugin eingereicht habe … wie schwer kann das schon sein? :wink:

Außerdem finde ich es wichtig, die Identitätsverwaltung bei einem Unternehmen zu unterstützen, das sich mehr auf Datenschutz konzentriert als, ähm, andere, die wir nennen könnten.

13 „Gefällt mir“

Mach es, @merefield!

Da es bereits eine Omniauth-Apple-Strategie gibt, sollte das machbar sein: GitHub - nhosoya/omniauth-apple: OmniAuth strategy for Sign In with Apple · GitHub

16 „Gefällt mir“

Sehr nützlich, danke, Rafael.

Jetzt sind wir fast am Ziel, aber wir sind auf ein Hindernis gestoßen:

Die OAuth-Strategie erfordert eine pem-Schlüsseldatei (die Sie von den netten Leuten bei Apple erhalten).

Wenn ich versuche, diese in einer SiteSetting zu speichern, wird der Text irgendwie beschädigt und die Generierung des privaten Schlüssels schlägt fehl:

::OpenSSL::PKey::EC.new(options.pem)

# OpenSSL::PKey::ECError

## invalid curve name

Ich habe versucht, den Text mit \n an den Stellen zu escapen, an denen Zeilenumbrüche sind.

Ich kann nicht erkennen, wie dies einsatzbereit sein kann, es sei denn, wir können den Inhalt dieser Datei irgendwie in einer SiteSetting speichern.

1 „Gefällt mir“

Die .pem-Datei ist doch nur der öffentliche Schlüssel, oder?

In diesem Fall ist der private Schlüssel enthalten (anscheinend sind noch andere Dinge darin kodiert).

Der Code verwendet diesen privaten Schlüssel anschließend, um das Client-Secret zu generieren.

Ich habe die Bibliothek mit der PEM-Datei getestet, und sie ist gültig. Sobald Sie die Datei jedoch in eine SiteSetting einfügen, wird sie (vielleicht vorhersehbar) subtil verändert.

UPDATE: Es sieht so aus, als ob \n in SiteSettings durch \\n ersetzt wird. Vielleicht kann man also bei der Abfrage nach \\ suchen und es um ein Zeichen kürzen.

Anscheinend habe ich das Problem lösen können. Entschuldigung für den Spam.

7 „Gefällt mir“

Ein Update:

Mein Plugin funktioniert bis zu einem gewissen Punkt, jedoch erhalte ich derzeit eine vage Fehlermeldung von Apple, wenn ich versuche, mich mit den von mir als Apple Developer eingerichteten Anmeldedaten zu authentifizieren:

“Ihre Anfrage konnte aufgrund eines Fehlers nicht abgeschlossen werden. Bitte versuchen Sie es später erneut.”

Wie Sie sich vorstellen können, gibt mir das nicht viel Handhabe.

Das wird etwas erschwert, da ihr Autorisierungsschema sich stark vom OAuth-2.0-Standard unterscheidet.

Leider kann ich bei Apple noch kein vollständiges TSI-Ticket eröffnen, da die Funktion noch nicht veröffentlicht ist, aber ich werde ein Feedback-Problem einreichen.

Das Repository finden Sie hier:

NB: Auf eigene Gefahr verwenden – noch nicht erfolgreich getestet!

7 „Gefällt mir“

Vielleicht laden wir die pem-Datei hoch? Wie groß ist sie?

Es ist winzig :slight_smile:

Die PEM-„Datei

8 „Gefällt mir“

@merefield Es läuft erfolgreich auf sandbox.dtaylor.uk :tada:

Ich musste ein paar Änderungen in unserem Fork vornehmen, um die Domänenverifizierung zu ermöglichen. Außerdem habe ich einige spezifischere Beschreibungen für die Seiteneinstellungen hinzugefügt und die Unterstützung für mehrzeilige PEM-Daten aktiviert.

Es sieht so aus, als würde das omniauth-apple-Gem (noch?) keine Informationen über den Benutzer übergeben können – was für uns nicht besonders nützlich ist. Es scheint, dass sign-in-with-apple fast mit OpenID-Connect kompatibel ist, sodass es möglich sein könnte, einige Funktionen dieses Plugins wiederzuverwenden.

Bezüglich der Einrichtung der Zugangsdaten habe ich diesen (sehr passend benannten) Blogbeitrag als weitaus nützlicher empfunden als die Dokumentation von Apple:

11 „Gefällt mir“

Das ist großartig! Ah, textarea ist für mich neu. Das umgeht meinen ‚Hack’, den ich hinzugefügt habe, auf elegante Weise. Perfekt! Hätte ich das nur gewusst! :sweat_smile:

Mir gefällt die von dir hinzugefügte Textdatei-Verifizierung, ein schöner Touch. Ich habe das bisher manuell gemacht, aber das ist eine große Hilfe für den Einsatz in der Produktion.

Ja, ich habe den auch verwendet.

Leider bekomme ich nach dem Zusammenführen deines Forks immer noch denselben Fehler auf Apple-Seite, also vermute ich, dass ich bei den Zugangsdaten immer noch etwas Dummes mache. Vielleicht schreibe ich dir eine PN, wenn ich darf, um uns auszutauschen! :wink:

7 „Gefällt mir“

OK, es hat sich herausgestellt, dass mein Problem fast sicher darin bestand, auf eine teilweise entwickelte Site zuzugreifen (die mit Nginx und über HTTPS läuft).

Ich habe es erneut mit einer Produktions-Site versucht und :tada:

aber leider wird, wie du sagst, „Name

Sind wir uns sicher, dass ein Name zurückgegeben wird? Aus Datenschutzsicht ist es fast besser, wenn der Benutzer einen Namen auswählt, als dass dabei öffentlich zugängliche personenbezogene Daten preisgegeben werden.

Technisch sollte es funktionieren? Aber ich stimme deinem Punkt zu, obwohl du entscheiden kannst, es auf der Apple-Seite nicht preiszugeben. Wie sich bisher herausgestellt hat, ist es ohnehin irrelevant!

Ja, jemand hatte bereits ein Problem dazu gemeldet, es wurde jedoch anschließend geschlossen.

Ich habe dazu einen Kommentar hinterlassen

Ich vermute, dass dies der Bereich des Codes ist, der uns beschäftigt:?

      info do
        { sub: id_token['sub'] }
      end

während wir beispielsweise im Discord-Auth-Gem dies erhalten:

      info do
        {
          name: raw_info['username'],
          email: raw_info['verified'] ? raw_info['email'] : nil,
          image: "https://cdn.discordapp.com/avatars/#{raw_info['id']}/#{raw_info['avatar']}"
        }
      end

Zur Info: In der API-Dokumentation von Apple werden diese Felder nicht erwähnt …

Es sieht so aus, als würde dieser PR nützliche Benutzerinformationen hinzufügen: Use JWT gem and some refactor by fjaeger · Pull Request #7 · nhosoya/omniauth-apple · GitHub. Hoffentlich wird er bald gemergt, oder falls nicht, könnten wir eine Fork in Betracht ziehen.

5 „Gefällt mir“

Ja, du hast recht. Ich habe diesen PR gesehen, aber den Code nicht im Detail geprüft und dachte, es gehe lediglich um den Wechsel zu einer anderen Abhängigkeit. Man sollte es vermeiden, PRs mit einem so riesigen Umfang einzureichen, da Details wie diese leicht untergehen können.

Wie du gesagt hast:

        {
          sub: id_info['sub'],
          email: user_info.dig('email'),
          first_name: user_info.dig('name', 'firstName'),
          last_name: user_info.dig('name', 'lastName'),
          extra: {
            raw_info: id_info.merge(user_info)
          }
        } 

Ich habe einen Kommentar hinzugefügt, um den PR zu unterstützen.

4 „Gefällt mir“