Ήμασταν όλοι εκεί. Δουλεύετε στο back-end του API και είστε ικανοποιημένοι με την πορεία του. Ολοκληρώσατε πρόσφατα το ελάχιστο βιώσιμο προϊόν (MVP), όλες οι δοκιμές περνούν και ανυπομονούμε να εφαρμόσετε ορισμένες νέες λειτουργίες.
Στη συνέχεια, το αφεντικό σας στέλνει ένα μήνυμα ηλεκτρονικού ταχυδρομείου: «Παρεμπιπτόντως, πρέπει να επιτρέψουμε στους χρήστες να συνδεθούν μέσω Facebook και Google. δεν πρέπει να δημιουργήσουν λογαριασμό μόνο για έναν μικρό ιστότοπο όπως ο δικός μας. '
Εξαιρετική. Το Scope creep χτυπά ξανά.
Προγραμματισμός ρομπότ c++
Τα καλά νέα είναι ότι το OAuth 2 έχει αναδειχθεί ως το βιομηχανικό πρότυπο για έλεγχο ταυτότητας κοινωνικού και τρίτου μέρους (χρησιμοποιείται από υπηρεσίες όπως το Facebook, το Google κ.λπ.), ώστε να μπορείτε να εστιάσετε στην κατανόηση και την εφαρμογή αυτού του προτύπου για να υποστηρίξετε ένα ευρύ φάσμα παροχείς κοινωνικής πιστοποίησης .
Είναι πιθανό να μην είστε εξοικειωμένοι με το OAuth 2. Δεν ήμουν, όταν μου συνέβη αυτό.
Σαν Προγραμματιστής Python , το ένστικτό σας μπορεί να σας οδηγήσει κουκούτσι , το προτεινόμενο εργαλείο Python Package Index (PyPA) για την εγκατάσταση πακέτων Python. Τα κακά νέα είναι ότι ο pip γνωρίζει περίπου 278 πακέτα που ασχολούνται με το OAuth - 53 από τα οποία αναφέρονται συγκεκριμένα Τζάνγκο . Αξίζει να δουλέψετε μια εβδομάδα μόνο για να ερευνήσετε τις επιλογές, μην ξεχάσετε να αρχίσετε να γράφετε κώδικα.
Σε αυτό το σεμινάριο, θα μάθετε πώς να ενσωματώνετε το OAuth 2 στο Django ή στο Πλαίσιο ανάπαυσης Django χρησιμοποιώντας Python Social Auth . Αν και αυτό το άρθρο επικεντρώνεται στο Django REST Framework, μπορείτε να εφαρμόσετε τις πληροφορίες που παρέχονται εδώ για να τις εφαρμόσετε σε μια ποικιλία άλλων κοινών back-end πλαισίων.
Μια γρήγορη επισκόπηση της ροής OAuth 2
Το OAuth 2 σχεδιάστηκε από την αρχή ως πρωτόκολλο ελέγχου ταυτότητας ιστού. Αυτό δεν είναι το ίδιο σαν να είχε σχεδιαστεί ως πρωτόκολλο ελέγχου ταυτότητας. υποθέτει ότι εργαλεία όπως η απόδοση HTML και οι ανακατευθύνσεις του προγράμματος περιήγησης είναι διαθέσιμα σε εσάς.
Αυτό είναι προφανώς κάτι εμπόδιο για ένα API που βασίζεται σε JSON, αλλά μπορείτε να το αντιμετωπίσετε.
Θα περάσετε από τη διαδικασία σαν να γράφετε έναν παραδοσιακό ιστότοπο από διακομιστή.
Η ροή OAuth 2 από τον διακομιστή
Το πρώτο βήμα συμβαίνει εκτός της ροής της εφαρμογής εντελώς. Ο κάτοχος του έργου πρέπει να εγγράψει την αίτησή σας σε κάθε πάροχο OAuth 2 για τον οποίο χρειάζεστε συνδέσεις.
Κατά τη διάρκεια αυτής της εγγραφής, παρέχουν στον πάροχο OAuth 2 ένα URI επανάκλησης , στην οποία η αίτησή σας θα είναι διαθέσιμη για λήψη αιτημάτων. Σε αντάλλαγμα, λαμβάνουν ένα κλειδί πελάτη και μυστικό πελάτη . Αυτά τα διακριτικά ανταλλάσσονται κατά τη διαδικασία ελέγχου ταυτότητας για την επικύρωση των αιτημάτων σύνδεσης.
Τα διακριτικά αναφέρονται στον κωδικό διακομιστή ως πελάτη. Ο κεντρικός υπολογιστής είναι ο πάροχος OAuth 2. Δεν προορίζονται για τους πελάτες του API σας.
Η ροή ξεκινά όταν η εφαρμογή σας δημιουργεί μια σελίδα που περιλαμβάνει ένα κουμπί, όπως 'Σύνδεση με Facebook' ή 'Σύνδεση με Google+'. Βασικά, αυτά δεν είναι τίποτα άλλο από απλούς συνδέσμους, καθένας από τους οποίους οδηγεί σε μια διεύθυνση URL όπως η ακόλουθη:
https://oauth2provider.com/auth? response_type=code& client_id=CLIENT_KEY& redirect_uri=CALLBACK_URI& scope=profile& scope=email (Σημείωση: Διακοπές γραμμής που έχουν εισαχθεί στο URI παραπάνω για αναγνωσιμότητα.)
Παρέχετε το κλειδί του πελάτη σας και ανακατευθύνετε το URI, αλλά δεν υπάρχουν μυστικά. Σε αντάλλαγμα, έχετε πει στον διακομιστή ότι θέλετε έναν κωδικό ελέγχου ταυτότητας ως απόκριση και πρόσβαση τόσο στα πεδία 'προφίλ' όσο και σε 'email'. Αυτά τα πεδία ορίζουν τα δικαιώματα που ζητάτε από τον χρήστη και περιορίζουν την εξουσιοδότηση του διακριτικού πρόσβασης που λαμβάνετε.
Μετά την παραλαβή, το πρόγραμμα περιήγησης του χρήστη κατευθύνεται σε μια δυναμική σελίδα που ελέγχει ο πάροχος OAuth 2. Ο πάροχος OAuth 2 επαληθεύει ότι το URI επιστροφής κλήσης και το κλειδί πελάτη ταιριάζουν μεταξύ τους πριν προχωρήσετε. Εάν συμβαίνει αυτό, η ροή αποκλίνει για λίγο ανάλογα με τα διακριτικά περιόδου σύνδεσης του χρήστη.
Εάν ο χρήστης δεν έχει συνδεθεί αυτήν τη στιγμή στην υπηρεσία, θα του ζητηθεί να το κάνει. Μόλις συνδεθεί, στον χρήστη εμφανίζεται ένας διάλογος που ζητά άδεια για να επιτρέψει στην εφαρμογή σας να συνδεθεί.
Υποθέτοντας ότι ο χρήστης εγκρίνει, ο διακομιστής OAuth 2 στη συνέχεια τους ανακατευθύνει στο URI επιστροφής κλήσης που παρείχατε, συμπεριλαμβανομένου ενός Κωδικός Εξουσιοδότησης στις παραμέτρους ερωτήματος: GET https://api.yourapp.com/oauth2/callback/?code=AUTH_CODE.
Ο κωδικός εξουσιοδότησης είναι ένα διακριτικό μίας χρήσης που λήγει γρήγορα. αμέσως μετά την παραλαβή του, ο διακομιστής σας θα πρέπει να γυρίσει και να υποβάλει άλλο αίτημα στον πάροχο OAuth 2, συμπεριλαμβανομένου τόσο του κωδικού εξουσιοδότησης όσο και του μυστικού του πελάτη σας:
POST https://oauth2provider.com/token/? grant_type=authorization_code& code=AUTH_CODE& redirect_uri=CALLBACK_URI& client_id=CLIENT_KEY& client_secret=CLIENT_SECRET Ο σκοπός αυτού του κωδικού εξουσιοδότησης είναι ο έλεγχος ταυτότητας του αιτήματος POST παραπάνω, αλλά λόγω της φύσης της ροής, πρέπει να δρομολογηθεί μέσω του συστήματος του χρήστη. Ως εκ τούτου, είναι εγγενώς ανασφαλές.
Οι περιορισμοί στον κωδικό εξουσιοδότησης (δηλαδή, ότι λήγει γρήγορα και μπορούν να χρησιμοποιηθούν μόνο μία φορά) υπάρχουν για να μετριαστεί ο εγγενής κίνδυνος μετάδοσης διαπιστευτηρίων ελέγχου ταυτότητας μέσω ενός μη αξιόπιστου συστήματος.
Αυτή η κλήση, που πραγματοποιείται απευθείας από τον διακομιστή σας στον διακομιστή του παροχέα OAuth 2, είναι το βασικό στοιχείο της διαδικασίας σύνδεσης από τον διακομιστή OAuth 2. Ο έλεγχος της κλήσης σημαίνει ότι γνωρίζετε ότι η κλήση είναι ασφαλής με TLS, συμβάλλοντας έτσι στην προστασία από επιθέσεις μέσω τηλεφωνικής σύνδεσης.
Η συμπερίληψη του κωδικού εξουσιοδότησης διασφαλίζει ότι ο χρήστης έχει εκχωρήσει ρητά τη συγκατάθεσή του. Η συμπερίληψη του μυστικού πελάτη, το οποίο δεν είναι ποτέ ορατό στους χρήστες σας, διασφαλίζει ότι αυτό το αίτημα δεν προέρχεται από κάποιο ιό ή κακόβουλο λογισμικό στο σύστημα του χρήστη, το οποίο παρεμπόδισε τον κωδικό εξουσιοδότησης.
Εάν όλα ταιριάζουν, ο διακομιστής επιστρέφει ένα διακριτικό πρόσβασης , με την οποία μπορείτε να πραγματοποιείτε κλήσεις σε αυτόν τον πάροχο ενώ ταυτόχρονα γίνεται έλεγχος ταυτότητας ως χρήστης.
Μόλις λάβετε το διακριτικό πρόσβασης από το διακομιστή, ο διακομιστής σας ανακατευθύνει στη συνέχεια το πρόγραμμα περιήγησης του χρήστη για άλλη μια φορά στη σελίδα προορισμού για χρήστες που μόλις έχουν συνδεθεί. Είναι σύνηθες να διατηρείτε το διακριτικό πρόσβασης στην προσωρινή μνήμη περιόδου σύνδεσης του διακομιστή, επομένως ότι ο διακομιστής μπορεί να πραγματοποιεί κλήσεις στον συγκεκριμένο κοινωνικό πάροχο όποτε είναι απαραίτητο.
Το διακριτικό πρόσβασης δεν πρέπει ποτέ να διατίθεται στον χρήστη!
Υπάρχουν περισσότερες λεπτομέρειες που θα μπορούσαμε να βυθίσουμε.
Για παράδειγμα, το Google περιλαμβάνει ένα ανανέωση διακριτικού που επεκτείνει τη διάρκεια ζωής του διακριτικού πρόσβασής σας, ενώ το Facebook παρέχει ένα τελικό σημείο στο οποίο μπορείτε να ανταλλάξετε διακριτικά πρόσβασης μικρής διάρκειας με κάτι μακρύτερο. Αυτές οι λεπτομέρειες δεν μας ενδιαφέρουν, ωστόσο, επειδή δεν πρόκειται να χρησιμοποιήσουμε αυτήν τη ροή.
Αυτή η ροή είναι δυσκίνητη για ένα REST API. Ενώ θα μπορούσατε να ζητήσετε από τον πελάτη front-end να δημιουργήσει την αρχική σελίδα σύνδεσης και να έχει το back-end να παρέχει μια διεύθυνση URL επιστροφής κλήσης, θα αντιμετωπίσετε τελικά ένα πρόβλημα. Θέλετε να ανακατευθύνετε το χρήστη στη σελίδα προορισμού του μπροστινού άκρου μόλις λάβετε το διακριτικό πρόσβασης και δεν υπάρχει σαφής, ΠΕΡΙΣΣΟΤΕΡΑ τρόπος να το κάνετε.
Ευτυχώς, υπάρχει μια άλλη ροή OAuth 2, η οποία λειτουργεί πολύ καλύτερα σε αυτήν την περίπτωση.
Η ροή OAuth 2 από την πλευρά του πελάτη
Σε αυτήν τη ροή, το front-end καθίσταται υπεύθυνο για το χειρισμό ολόκληρης της διαδικασίας OAuth 2. Γενικά μοιάζει με τη ροή από τον διακομιστή, με μια σημαντική εξαίρεση - οι διεπαφές ζουν ζωντανά σε μηχανήματα που ελέγχουν οι χρήστες, επομένως δεν μπορούν να εμπιστευτούν το μυστικό του πελάτη. Η λύση είναι απλώς να εξαλειφθεί ολόκληρο το βήμα της διαδικασίας.
Το πρώτο βήμα, όπως στη ροή από τον διακομιστή, είναι η εγγραφή της εφαρμογής.
Σε αυτήν την περίπτωση, ο κάτοχος του έργου εξακολουθεί να καταγράφει την εφαρμογή, αλλά ως εφαρμογή ιστού. Ο πάροχος OAuth 2 θα εξακολουθεί να παρέχει ένα κλειδί πελάτη , αλλά ενδέχεται να μην παρέχει κανένα μυστικό πελάτη.
Η διεπαφή παρέχει στον χρήστη ένα κουμπί κοινωνικής σύνδεσης, το οποίο κατευθύνει σε μια ιστοσελίδα που ελέγχει ο πάροχος του OAuth 2 και ζητά άδεια από την εφαρμογή μας να έχει πρόσβαση σε ορισμένες πτυχές του προφίλ του χρήστη.
Η διεύθυνση URL φαίνεται λίγο διαφορετική αυτή τη φορά:
https://oauth2provider.com/auth? response_type=token& client_id=CLIENT_KEY& redirect_uri=CALLBACK_URI& scope=profile& scope=email Σημειώστε ότι το response_type η παράμετρος αυτή τη φορά στο URL είναι token.
Τι γίνεται λοιπόν με το URI ανακατεύθυνσης;
Αυτή είναι απλώς οποιαδήποτε διεύθυνση στο μπροστινό μέρος που είναι έτοιμη να χειριστεί το διακριτικό πρόσβασης κατάλληλα.
Ανάλογα με τη βιβλιοθήκη OAuth 2 που χρησιμοποιείται, το front-end ενδέχεται να εκτελεί προσωρινά προσωρινά έναν διακομιστή ικανό να δέχεται αιτήματα HTTP στη συσκευή του χρήστη. Σε αυτήν την περίπτωση, το URL ανακατεύθυνσης έχει τη μορφή http://localhost:7862/callback/?token=TOKEN.
πώς να αποκτήσετε ένα ρομπότ
Επειδή ο διακομιστής OAuth 2 επιστρέφει μια ανακατεύθυνση HTTP μετά την αποδοχή του χρήστη και αυτή η ανακατεύθυνση επεξεργάζεται από το πρόγραμμα περιήγησης στη συσκευή του χρήστη, αυτή η διεύθυνση ερμηνεύεται σωστά, παρέχοντας πρόσβαση στο διακριτικό.
Εναλλακτικά, το front-end μπορεί άμεσα να εφαρμόσει μια κατάλληλη σελίδα. Σε κάθε περίπτωση, το front-end είναι υπεύθυνο, σε αυτό το σημείο, για την ανάλυση των παραμέτρων του ερωτήματος και την επεξεργασία του διακριτικού πρόσβασης.
Από εδώ και στο εξής, το front-end μπορεί να καλέσει απευθείας το API του παροχέα OAuth 2 χρησιμοποιώντας το διακριτικό. Όμως οι χρήστες δεν το θέλουν πραγματικά. θέλουν έλεγχο ταυτότητας στο API σας. Το μόνο που πρέπει να παρέχει το back-end είναι ένα τελικό σημείο στο οποίο το front-end μπορεί να ανταλλάξει ένα διακριτικό πρόσβασης ενός κοινωνικού παρόχου με ένα διακριτικό που παρέχει πρόσβαση στο API σας.
Γιατί να το επιτρέψετε καθόλου, δεδομένου ότι η παροχή του διακριτικού πρόσβασης στο front-end είναι εγγενώς λιγότερο ασφαλής από τη ροή από τον διακομιστή;
Η ροή από την πλευρά του πελάτη επιτρέπει έναν αυστηρότερο διαχωρισμό μεταξύ ενός REST API back-end και ενός front-end που βλέπει ο χρήστης. Δεν υπάρχει τίποτα που να σας εμποδίζει να ορίσετε τον διακομιστή υποστήριξης ως URI ανακατεύθυνσης. το τελικό αποτέλεσμα θα ήταν κάποιο είδος υβριδικής ροής.
Το ζήτημα είναι ότι ο διακομιστής πρέπει στη συνέχεια να δημιουργήσει μια κατάλληλη σελίδα που βλέπει ο χρήστης και, στη συνέχεια, τον έλεγχο χειρός πίσω στο front-end με κάποιο τρόπο.
Είναι σύνηθες στα σύγχρονα έργα να διαχωρίζουμε αυστηρά τις ανησυχίες μεταξύ διεπαφής χρήστη διεπαφής και παρασκηνίου που χειρίζεται όλη τη λογική της επιχείρησης. Συνήθως επικοινωνούν μέσω ενός καλά καθορισμένου API JSON. Η υβριδική ροή που περιγράφεται παραπάνω λασπώνει ότι ο διαχωρισμός των ανησυχιών, ωστόσο, αναγκάζει το οπίσθιο άκρο να εξυπηρετεί και μια σελίδα που βλέπει ο χρήστης, και στη συνέχεια σχεδιάζει κάποια ροή για κάποιον έλεγχο χειρός πίσω στο μπροστινό μέρος.
Επιτρέποντας στο front-end να χειριστεί το διακριτικό πρόσβασης είναι μια πρόσφορη τεχνική που διατηρεί τον διαχωρισμό των ανησυχιών. Αυξάνει κάπως τον κίνδυνο από έναν συμβιβασμένο πελάτη, αλλά λειτουργεί καλά, γενικά.
Αυτή η ροή μπορεί να φαίνεται περίπλοκη για το front-end και είναι, εάν χρειάζεστε την ομάδα front-end να αναπτύξει τα πάντα από μόνη της. Ωστόσο, και τα δύο Facebook και Google παρέχει βιβλιοθήκες που επιτρέπουν στο front-end να περιλαμβάνει κουμπιά σύνδεσης που χειρίζονται ολόκληρη τη διαδικασία με ελάχιστη διαμόρφωση.
Ακολουθεί μια συνταγή για ανταλλαγή διακριτικών στο παρασκήνιο.
Κάτω από τη ροή του πελάτη, το back-end είναι αρκετά απομονωμένο από τη διαδικασία OAuth 2. Μην παραπλανηθείτε: Δεν είναι απλή δουλειά. Θα θέλατε να υποστηρίζει τουλάχιστον τις ακόλουθες λειτουργίες.
- Στείλτε τουλάχιστον ένα αίτημα στον πάροχο OAuth 2, απλώς για να βεβαιωθείτε ότι το διακριτικό που παρέχεται από το front-end ήταν έγκυρο και όχι κάποια αυθαίρετη τυχαία συμβολοσειρά.
- Όταν το διακριτικό είναι έγκυρο, επιστρέψτε ένα έγκυρο διακριτικό για το API σας. Διαφορετικά, επιστρέψτε ένα ενημερωτικό σφάλμα.
- Εάν πρόκειται για νέο χρήστη, δημιουργήστε ένα
Userμοντέλο για αυτούς και να το συμπληρώσετε κατάλληλα. - Εάν αυτός είναι ένας χρήστης για τον οποίο a
Userτο μοντέλο υπάρχει ήδη, αντιστοιχίστε τα με τη διεύθυνση email τους, ώστε να αποκτήσουν πρόσβαση στον σωστό υπάρχοντα λογαριασμό αντί να δημιουργήσουν έναν νέο για την κοινωνική σύνδεση. - Ενημερώστε τις λεπτομέρειες προφίλ του χρήστη με βάση αυτά που έχουν παράσχει στα μέσα κοινωνικής δικτύωσης.
Τα καλά νέα είναι ότι η εφαρμογή όλων αυτών των λειτουργιών στο πίσω μέρος είναι πολύ απλούστερη από ό, τι θα περίμενε κανείς.
Εδώ είναι η μαγεία για το πώς να τα κάνετε όλα αυτά στο πίσω μέρος σε μόλις δύο δεκάδες γραμμές κώδικα. Αυτό εξαρτάται από το Python Social Auth βιβλιοθήκη ('PSA' στο εξής), οπότε θα πρέπει να συμπεριλάβετε και τα δύο social-auth-core και social-auth-app-django στο requirements.txt.
Θα πρέπει επίσης να διαμορφώσετε τη βιβλιοθήκη ως τεκμηριωμένη εδώ . Λάβετε υπόψη ότι αυτό αποκλείει κάποιο χειρισμό εξαιρέσεων για σαφήνεια
Μπορείτε να βρείτε τον πλήρη κωδικό για αυτό το παράδειγμα εδώ .
@api_view(http_method_names=['POST']) @permission_classes([AllowAny]) @psa() def exchange_token(request, backend): serializer = SocialSerializer(data=request.data) if serializer.is_valid(raise_exception=True): # This is the key line of code: with the @psa() decorator above, # it engages the PSA machinery to perform whatever social authentication # steps are configured in your SOCIAL_AUTH_PIPELINE. At the end, it either # hands you a populated User model of whatever type you've configured in # your project, or None. user = request.backend.do_auth(serializer.validated_data['access_token']) if user: # if using some other token back-end than DRF's built-in TokenAuthentication, # you'll need to customize this to get an appropriate token object token, _ = Token.objects.get_or_create(user=user) return Response({'token': token.key}) else: return Response( {'errors': {'token': 'Invalid token'}}, status=status.HTTP_400_BAD_REQUEST, ) Υπάρχουν μόνο λίγα περισσότερα που πρέπει να ακολουθήσετε στις ρυθμίσεις σας ( πλήρης κωδικός ) και μετά είστε έτοιμοι:
AUTHENTICATION_BACKENDS = ( 'social_core.backends.google.GoogleOAuth2', 'social_core.backends.facebook.FacebookOAuth2', 'django.contrib.auth.backends.ModelBackend', ) for key in ['GOOGLE_OAUTH2_KEY', 'GOOGLE_OAUTH2_SECRET', 'FACEBOOK_KEY', 'FACEBOOK_SECRET']: # Use exec instead of eval here because we're not just trying to evaluate a dynamic value here; # we're setting a module attribute whose name varies. exec('SOCIAL_AUTH_{key} = os.environ.get('{key}')'.format(key=key)) SOCIAL_AUTH_PIPELINE = ( 'social_core.pipeline.social_auth.social_details', 'social_core.pipeline.social_auth.social_uid', 'social_core.pipeline.social_auth.auth_allowed', 'social_core.pipeline.social_auth.social_user', 'social_core.pipeline.user.get_username', 'social_core.pipeline.social_auth.associate_by_email', 'social_core.pipeline.user.create_user', 'social_core.pipeline.social_auth.associate_user', 'social_core.pipeline.social_auth.load_extra_data', 'social_core.pipeline.user.user_details', ) Προσθέστε μια αντιστοίχιση σε αυτήν τη λειτουργία στο urls.py και είστε έτοιμοι!
Πώς λειτουργεί αυτή η μαγεία;
Το Python Social Auth είναι ένα πολύ δροσερό, πολύπλοκο κομμάτι μηχανημάτων. Είναι απόλυτα χαρούμενο που χειρίζεστε τον έλεγχο ταυτότητας και την πρόσβαση σε οποιοδήποτε αρκετές δωδεκάδες παροχείς κοινωνικών αδειών , και λειτουργεί σε πιο δημοφιλή πλαίσια Ιστού της Python, όπως Τζάνγκο , Φλάσκα , Πυραμίδα , CherryPy , και WebPy .
Ως επί το πλείστον, ο παραπάνω κώδικας είναι μια πολύ τυπική προβολή με βάση τη λειτουργία Django REST framework (DRF): Ακούει αιτήματα POST σε όποια διαδρομή τον αντιστοιχίζετε στο urls.py και, με την προϋπόθεση ότι θα του στείλετε ένα αίτημα με τη μορφή που αναμένει, θα σας πάρει ένα User αντικείμενο, ή None.
Εάν λάβετε ένα User αντικείμενο, είναι του τύπου μοντέλου που έχετε διαμορφώσει αλλού στο έργο σας, ο οποίος μπορεί να υπήρχε ή όχι. Το PSA φρόντισε ήδη να επικυρώσει το διακριτικό, να προσδιορίσει εάν υπήρχε ή όχι αντιστοίχιση χρήστη, να δημιουργήσει έναν χρήστη εάν είναι απαραίτητο και να ενημερώσει τα στοιχεία χρήστη από τον κοινωνικό φορέα.
Οι ακριβείς λεπτομέρειες σχετικά με τον τρόπο αντιστοίχισης ενός χρήστη από τον χρήστη του κοινωνικού παρόχου στον δικό σας και συσχετίζονται με υπάρχοντες χρήστες, καθορίζονται από το SOCIAL_AUTH_PIPELINE ορίζεται παραπάνω. Υπάρχουν πολλά περισσότερα για να μάθετε πώς λειτουργεί όλα αυτά, αλλά δεν εμπίπτουν στο πεδίο αυτής της ανάρτησης. Μπορείτε να διαβάσετε περισσότερα γι 'αυτό εδώ .
Το βασικό κομμάτι της μαγείας είναι το @psa() διακοσμητής στην προβολή, η οποία προσθέτει ορισμένα μέλη στο request αντικείμενο που περνά στην προβολή σας. Το πιο ενδιαφέρον για εμάς είναι request.backend (στο PSA, ένα backend είναι οποιοσδήποτε πάροχος κοινωνικού ελέγχου ταυτότητας).
Το κατάλληλο back-end επιλέχθηκε για εμάς και προσαρτήθηκε στο request αντικείμενο με βάση το backend όρισμα στην προβολή, η οποία συμπληρώνεται από το ίδιο το URL.
Μόλις αποκτήσετε το backend αντικειμένου στο χέρι, είναι απόλυτα χαρούμενο να σας πιστοποιήσουμε τον συγκεκριμένο πάροχο, δεδομένου του κωδικού πρόσβασής σας. αυτό είναι το do_auth μέθοδος. Αυτό, με τη σειρά του, εμπλέκει το σύνολο του SOCIAL_AUTH_PIPELINE από το αρχείο ρυθμίσεων.
Ο αγωγός μπορεί να κάνει αρκετά ισχυρά πράγματα αν το επεκτείνετε, αν και ήδη κάνει ό, τι χρειάζεστε με τίποτα άλλο από την προεπιλεγμένη, ενσωματωμένη λειτουργικότητά του.
Μετά από αυτό, επιστρέφει στον κανονικό κωδικό DRF: εάν έχετε έγκυρο User αντικείμενο, μπορείτε πολύ εύκολα να επιστρέψετε ένα κατάλληλο διακριτικό API. Εάν δεν λάβατε έγκυρο User αντικειμένου πίσω, είναι εύκολο να δημιουργήσετε ένα σφάλμα.
Ένα μειονέκτημα αυτής της τεχνικής είναι ότι, ενώ είναι σχετικά απλό να επιστραφούν σφάλματα εάν προκύψουν, είναι δύσκολο να πάρετε πολλές πληροφορίες σχετικά με το τι πήγε στραβά. Το PSA καταπίνει οποιεσδήποτε λεπτομέρειες ενδέχεται να έχει επιστρέψει ο διακομιστής σχετικά με το πρόβλημα.
Και πάλι, είναι στη φύση των καλά σχεδιασμένων συστημάτων ελέγχου ταυτότητας να είναι αρκετά αδιαφανής σχετικά με τις πηγές σφαλμάτων. Εάν μια εφαρμογή λέει ποτέ σε έναν χρήστη 'Μη έγκυρο κωδικό πρόσβασης' μετά από μια προσπάθεια σύνδεσης, αυτό ισοδυναμεί με το ρητό 'Συγχαρητήρια! Μαντέψατε ένα έγκυρο όνομα χρήστη. '
Γιατί να μην κυλήσετε μόνοι σας;
Με μια λέξη: επεκτασιμότητα. Πολύ λίγοι παροχείς κοινωνικών δικτύων OAuth 2 απαιτούν ή επιστρέφουν ακριβώς τις ίδιες πληροφορίες στις κλήσεις API τους με τον ίδιο ακριβώς τρόπο. Υπάρχουν όμως όλα τα είδη ειδικών περιπτώσεων και εξαιρέσεων.
Η προσθήκη ενός νέου παροχέα υπηρεσιών κοινωνικής δικτύωσης μόλις ρυθμίσετε ήδη ένα PSA είναι θέμα μερικών γραμμών διαμόρφωσης στα αρχεία ρυθμίσεων. Δεν χρειάζεται να προσαρμόσετε καθόλου κώδικα. Το PSA αφαιρεί όλα αυτά, έτσι ώστε να εστιάζετε στη δική σας εφαρμογή.
Πώς μπορώ να το δοκιμάσω στη Γη;
Καλή ερώτηση! unittest.mock δεν ταιριάζει σωστά για να χλευάσουμε τις κλήσεις API που είναι θαμμένες κάτω από ένα επίπεδο αφαίρεσης βαθιά μέσα σε μια βιβλιοθήκη. Η ανακάλυψη του ακριβούς δρόμου για τη χλεύη θα απαιτούσε σημαντική προσπάθεια.
Αντ 'αυτού, επειδή το PSA είναι χτισμένο πάνω στη βιβλιοθήκη αιτημάτων, χρησιμοποιείτε το εξαιρετικό Απαντήσεις βιβλιοθήκη για να χλευάσουμε τους παρόχους σε επίπεδο HTTP.
Μια πλήρης συζήτηση για τις δοκιμές είναι πέρα από το πεδίο αυτού του άρθρου, αλλά συμπεριλαμβάνεται ένα δείγμα των δοκιμών μας εδώ . Ιδιαίτερες συναρτήσεις που πρέπει να σημειωθούν είναι οι mocked διαχειριστής περιβάλλοντος και το SocialAuthTests τάξη.
Αφήστε το PSA να κάνει τη βαριά ανύψωση.
Η διαδικασία OAuth2 είναι λεπτομερής και περίπλοκη με πολλή εγγενή πολυπλοκότητα. Ευτυχώς, είναι δυνατόν να παρακάμψετε μεγάλο μέρος αυτής της πολυπλοκότητας, φέρνοντας μια βιβλιοθήκη αφιερωμένη στον χειρισμό της με όσο το δυνατόν ανώδυνο τρόπο.
Το Python Social Auth κάνει εξαιρετική δουλειά σε αυτό. Έχουμε δείξει μια προβολή Django / DRF που χρησιμοποιεί τη ροή OAuth2 από την πλευρά του πελάτη, για να εξασφαλίσει την απρόσκοπτη δημιουργία και αντιστοίχιση χρηστών σε μόνο 25 γραμμές κώδικα. Δεν είναι πολύ άθλιο.
