Devise, Confirmation, Omniauth ... a filozofia

Dyskusje
1

Załóżmy hipotetycznie, że piszecie aplikację, gdzie użytkownicy mogą sobie coś wybrać, zapłacić za zamówione towary i czekać na przesyłkę.
Co jest potrzebne sprzedającemu?

  1. Informacja o tym, kto zamawiał
  2. Adres na który ma być wysłany towar,
  3. info o tym, czy zapłacił (dla modelu biznesowego “zapałać i odbierz”) lub, czy jest to kolejne zamówienie, a wcześniejsze jeszcze nie jest rozliczone (dla modelu “odbierz i zapłać”)

No dobra… Piszemy w Railsach z wykorzystaniem Devise, Omniauth i logowaniem z różnych portali społecznościowych typu FB, GitHub, Google, Linkedin…

Zadaję pytanie wprost:
Jaki sens ma ciche i błyskawiczne rejestrowanie z wykorzystaniem autoryzacji z takiego np Google, gdy użytkownik nie wypełni formularza z dodatkowymi informacjami typu adres dostawy, nazwa odbiorcy, etc?

W jakim celu dajemy możliwość szybkiego rejestrowania do naszej aplikacji (bez wypełniania szczegółowego formularza)?
Po to, by klient, który w naszym systemie aktualnie jest widziany jako “Alibaba” (alibaba@gmail.com) blokował nam towary w naszych stanach magazynowych?

Uważam, że sensownym podejściem do tematu jest:

  1. Nie logować go wcale do chwili, gdy nie zdecyduje się na wybieranie towarów, a wtedy musi zarejestrować się wypełniając dokładnie swój formularz danych (Nazwa, adres, etc)
  2. Przy rejestrowaniu zmusić go do wypełnienia formularza danych, tak, by następne logowania mogły być szybkie i ciche

Niech ktoś mi wyjaśni celowość rozwiązania polegającego na tym, że rejestrujący się (po autoryzacji z przykładowego Fejsa) user musi tylko potwierdzić swój email, na który dostanie link, by mógł zakończyć proces confirmation?
Jeżeli przy rejestracji nie wypełni dodatkowo pól password i confirm_password, to przecież nawet nie będzie mógł zalogować się bez linku z takiego Fejsa, bo hasła nie zna w naszym systemie (wygenerowano mu automatycznie).
Nie zna hasła, to nie uzupełni swoich danych!
Będzie musiał zatem przejść ścieżkę:

  1. Rejestrowanie z portalu społecznościowego z “ręcznym” podaniem email’a
  2. Potwierdzenie swojego maila
  3. Wysłanie linku resetu hasła
  4. Ponowny powrót do swojej skrzynki pocztowej i wybranie przysłanego linku z resetem hasła
  5. Zmiana hasła po przekierowaniu na naszą stronę.

I to ma być to userfrendly rozwiązanie?
MAKABRA!

Zatem uważam, że kompletnym bezsensem (dla takiego typu aplikacji), jest rejestrowanie użytkowników, którzy jesynie muszą potwierdzić swój email.

Sprawa druga, to konta użytkowników.
Znalazłem przykład aplikacji, (http://sourcey.com/rails-4-omniauth-using-devise-with-twitter-facebook-and-linkedin/) która pozwala rejestrować użytkowników i umożliwia im podanie @maila w celu zakończenia procesu rejestracji.

Pytam, w jakim celu?
Ma to sens tylko w przypadku Twittera’ który nie zwraca w module Omniauth adresu email, a podaje samą nazwę usera.
Zostawmy zresztą chwilowo Twittera na boku.

W powyższym przykładzie został bardzo fajnie pokazany model relacji

jedno konto User i wiele kont Identity,
które odzwierciedlać mają wszystkie konta portali społecznościowych, z których się user logował.
Ok i super, ale pytam o sens tego przykładu, skoro użytkownik ma potwierdzić adres @email?

Nie wiem, może ja nie rozumiem do końca filozofii tego przykładu i ogólnie filozofii rejestrowania użytkowników, ale uważam, że dla internetowego biznesu, to właśnie @email jest takim “PESELEM”, którym powinniśmy się posługiwać zakładając unikalne konta użytkowników.
Prosty przykład:

tabela User:
id, name, email
11, Alibaba, alibaba@gmail.com

tabela Identity:
id, user_id, provider, uid, name, email
51, 11, facebook, 12345678, Alibaba, alibaba@gmail.com
87, 11, github, 3123132344, Zenek Bębenek, alibaba@gmail.com
93, 11, linkedin, 1112222244444, Mizdrz , alibaba@gmail.com

Na każdym z tych portali społecznościowych nasz User ma różne nazwy i ma jedną wspólną cechę - email

Jaki zatem sens ma wypełnianie przez niego pola email w celu wysłania mu linku potwierdzającego jego konto pocztowe?

Uważam, że takie pole winno być wręcz zablokowane, bo co to za autoryzacja z przykładowego konta Fejsa związanego z adresem email alibaba@gmail.com i wysyłanie potwierdzenia na adres sampodałem@gmail.com?

Podzielcie się swoimi przemyśleniami w tej sprawie, gdyż albo nie rozumiem filozofii autoryzacji albo nie rozumiem akademickiego przykładu z możliwością wysyłania linku confirmation na adres zupełnie niezwiązany z adresem email, jaki user ma u providera

2

Wstęp, Rozwinięcie, Pytanie (w tej kolejności) a teraz do rzeczy

Omniauth służy do logowania przez zewnętrzne serwisy Oauth, to czy pozwolisz użytkownikowi zalogowanemu w ten sposób umożliwić logowanie dodatkowo za pomocą loginu i hasła to twoja decyzja (jedne serwisy tak robią inne nie)

3

Twój post brzmi jakbyś się oburzał na to, że istnieje możliwość rejestracji/logowania przez OAuth. Ten flow rejestracji rzeczywiście jest daleki od ideału, ale to dlatego, że dokładasz tam niepotrzebne kroki:

  1. wcale nie muszę potwierdzać maila (skoro mój mail przyszedł w requeście z FB to znaczy, że jest potwierdzony, jedynie w przypadku Twittera jest to konieczne)
  2. nie muszę wymyślać hasła (będę się logował przez FB)

Tak więc flow jest bardzo prosty:

  1. Klikam “połącz z FB”
  2. potwierdzam autoryzację aplikacji
  3. otrzymujesz moje dane: imię, nazwisko i maila
  4. wyświetlasz mi tylko formularz do danych do dostawy
  5. zapisujesz sobie dane i następnym razem nie muszę już ich podawać

Przy następnym logowaniu mój proces zamawiania wygląda tak:

  1. Klikam “zaloguj przez FB”
  2. Potwierdzam zakup
4

Tak więc flow jest bardzo prosty:

  1. Klikam “połącz z FB”
  2. potwierdzam autoryzację aplikacji
  3. otrzymujesz moje dane: imię, nazwisko i maila
  4. wyświetlasz mi tylko formularz do danych do dostawy
  5. zapisujesz sobie dane i następnym razem nie muszę już ich podawać

Zdaje się, że moja droga także miała 5 kroków :wink: :smiley:

Nie, nie oburzam się, że istnieje możliwość rejestracji/logowania przez OAuth.
Stawiam pytanie, czy ma sens potwierdzanie adresu email (przy logowaniu OAuth), to raz.
Dwa, pytam, czy w aplikacjach, które potrzebują dodatkowych danych, ma sens szybka rejestracja, bez uzupełniania natychmiast tych dodatkowych informacji.

Stawiam pytanie, czy jest nam potrzebny zarejestrowany user, który może coś pobierać do koszyka (blokować stany magazynowe) jeżeli nie posiadamy jego pełnych danych.

Chciałbym wstrzymać konie tych, którzy pragną mi imputować, że kwestionuję sens logowania z portali społecznościowych.

5

Nie ma. Są co prawda strony, które jedyne co robią to pobierają dane z FB i wklejają je do formularza, ale to strasznie irytujące.

Tak jak wspomniałem wyżej, nie muszę wymyślać hasła ani potwierdzać maila, więc dla mnie, jako użytkownika, jest to wygodniejsze.

Na to pytanie chyba nie ma jednej odpowiedzi dla każdego sklepu. Są takie, gdzie brak towaru to rzadkość i nie muszą się tym przejmować, są takie, które nie będą blokowały towaru dopóki user nie złoży zamówienia lub przynamniej nie poda adresu, a są takie, gdzie może rzeczywiście lepiej lepiej nie dawać użytkownikom rejestracji przez OAuth, bo spowoduje to więcej problemów niż pożytku.

1 Like
6

O to właśnie mi chodzi.

Kiedy ma sens stosowanie cichej rejestracji* (przez OAuth), skoro użytkownik musi i tak wypełnić dodatkowe pola, jeżeli chce cokolwiek zamówić?

Może ktoś podać przykład, gdzie potrzebna(!) jest rejestracja usera z niepełnymi danymi (np. tylko email) i nie ma potrzeby późniejszego uzupełniania ich?
Poza listami mailingowymi jakoś nie widzę innych zastosowań.

(*) - podkreślam REJESTRACJI, bo późniejsze logowanie, gdy jego dane profilowe są już wypełnione, to inna bajka.

7

Chcesz umożliwić zarejestrowyn uzytkownikom przez OAuth logowanie za pomocą loginu i hasła, z tego co zrozumiałem. Tych danych uzytkownicy nie posiadaja (na pewno nie mają hasła). Nie wiem jakich danych tobie brakuje po zalogowaniu przez OAuth

8

A chcę pozwolić logować się też “normalnie” (bez pomocy OAuth), gdyż uważam, że każdy zarejestrowany u mnie User może, lecz nie musi(!), logować się do mojego portalu poprzez OAuth.

Abstrakcyjny może trochę przykład, ale co ma zrobić człowiek, który autoryzował się u mnie poprzez konto na Fejsie, a później, z przyczyn np. prawnych, to konto na FB zablokowano mu?
Ja też automatycznie mam go odciąć od mojego portalu?
A jeżeli nie, to ma zakładać nowe konto z nowym(!) adresem email?
Dlatego uważam, że logowanie bezpośrednio do mojego sklepu musi być zawsze, natomiast logowanie z wykorzystaniem OAuth może być. … Tylko “może być” lecz na pewno “nie musi”.

I dokładnie z tych samych powodów uważam, że już na etapie rejestracji, użytkownik powinien uzupełnić swoje dane (adres, nazwa, a przede wszystkim hasło)

9

jeśli tak podchodzisz do sprawy to w takim razie po zalogowaniu przez OAuth musisz przekierować użytkownika do formularza uzupełnienia danych.

10

Jasne, użytkownicy powinni też móc logować się z pomocą maila i hasła. Ja robię tak, że generuję użytkownikowi jakieś hasło. Jeżeli użytkownik zarejestrował się przez facebooka, ale chce zalogować się hasłem, po prostu resetuje je (wypełnia formularz ‘nie pamiętam hasła’) i tyle

11

OK.
A czy użytkownik musi potwierdzać hasłem zmiany (uzupełnienie danych) swojego konta?
Bo jeżeli nie, to … :open_mouth:
a jeżeli tak, to wg Twojej koncepcji:

  1. Pierwsze logowanie (rejestrowanie) przez OAuth
    Aby cokolwiek zamówić i robić cokolwiek innego niż anonim(!) musi teraz
  2. wysłać do siebie link o zmianę hasła
  3. przejść do poczty i wybrać link zmiany hasła
  4. zmienić hasło
  5. zmienić dane na formularzu kontaktów
  • Tak, teraz ten użytkownik już różni się od anonima.

Zadaję sobie pytanie, czy nie jest właściwe, aby zmienić trochę te kroki.
A) Pierwsza rejestracja ZAWSZE była z przekierowaniem, o którym pisze Wafcio, tak aby użytkownik uzupełnił swoje dane i wpisał swoje hasło. Każda następna wizyta u mnie może już pomijać to, bo użytkownik ma przecież wypełnione dane i zna swoje hasło.

B) Tak długo, jak długo użytkownik przegląda tylko dane (lub wykonuje dowolne operacje nie wymagające autoryzacji), nie rejestrować go wcale.

12

dlaczego uważasz że musi zmieniać hasło, przecież jest już zalgowany (przez OAuth)

A co szkodzi przy każdej wizycie logować się przez OAuth (z pominięciem sytuacji że konto np. na facebooku jest zablokowane)

13

Dlaczego koniecznie hasłem? Może potwierdzać je klikając w link potwierdzający w mailu.

Ale ja nie widzę tutaj zmiany, tylko uzupełnienie: nie rejestruj użytkownika tak długo jak nie jest to konieczne, jak chce się zarejestrować, daj mu możliwosć rejestracji albo przez OAuth albo przez maila i następnie wyświetl formularz do uzupełnienia pozostałych danych.

BTW z tym zablokowanym kontem na fejsie to trochę tak jak z utraconym dostępem do maila - co zrobisz, jak użytkownik straci dostęp do maila? Nie będzie mógł u Ciebie ani zresetować hasła, ani zmienić maila (bo zmiana maila powinna wymagać potwierdzenia ze starego adresu). Wg mnie stracisz dużo więcej czasu na rozważanie nad tym problemem niż po prostu pomagając użytkownikom w indywidualnych przypadkach.

14

Chyba :wink: nie bardzo. :smiley:
Skoro ma konto w mojej aplikacji i zna hasło do tego konta(!), to może się w niej zalogować używając emaila i hasła.
Następnie może dokonać stosownych zmian …m.in adresu email. i całość wprowadzonych zmian potwierdzić swoim hasłem.

I teraz już chyba jasne dlaczego użytkownik winien mieć już za pierwszym razem wprowadzone hasło

15

Przy każdej NASTĘPNEJ, nic już nie szkodzi.
Skoro użytkownik już ma hasło w mojej aplikacji, to kolejne logowania mogą już pomijać przekierowania do okna uzupełnienia danych

Uważam, że zmiany danych na koncie użytkownika winny być potwierdzane hasłem.
Głupio trochę, gdy wrócimy z sikania lub dłuższej kawy do komupera i zobaczymy tam okienko:

“Twoje dane zostały zmienione”

… a tam nowa nazwa, nowy email …(i nowe hasło zapewne) , bo dowcipny kolega zmienił to wszystko, bo przecież byłeś już zalogowany przez OAuth.

16

Zmiana polega na tym, że jak już zechce mu się rejestrować, to musi(!) też podać swoje hasło, by nie zostać z ręką w nocniku, gdy utraci dostęp do Fejsa i do maila.
Tak, zgadzam się, że jest to uzupełnienie …aczkolwiek dosyć (moim zdaniem) istotne.

17

@BSorbus sprecyzuj dokładnie jaki masz problem, bo albo ciebie nie rozumiem, albo nie możesz zrozumieć, że OAuth tak działa i próbujesz przekonać nie wiem kogo do swojej racji.

18

Ja nie rozumiem co tam widać. Masz podane 2 alternatywne rozwiązania i wg Ciebie one sugerują, że hasło jest konieczne O_o

IMHO szukasz na siłę przypadków, żeby udowodnić, że hasło jest potrzebne. Nie, nie jest. Mam konta w kilku aplikacjach, gdzie loguję się tylko przez OAuth i nie znam hasła. Jak stracę dostęp do konta to poproszę o wysłanie mi hasła mailem. Jak stracę dostęp do maila, to mam na tyle przerąbane, że dostęp do tych aplikacji będzie moim najmniejszym problemem.

19

Zacznijmy może od tego, że … NIE MAM PROBLEMU :stuck_out_tongue:
Wiem jak działa OAuth, to po drugie.
Do mojej racji nikogo nie chcę namawiać, to po trzecie.

A przechodząc kolejny raz do tych samych wątpliwości, o których wspomniałem wcześniej, ponawiam pytanie:

“Czy ma sens rejestrowanie użytkownika w systemie i nie wymuszanie na nim wprowadzania natychmiast dodatkowych danych (m.in hasła do naszego systemu)?”

20

A to Ci współczuję.
Jednak ułatwię Ci życie w mojej aplikacji i pozwolę Ci nadal w niej pracować, gdyż wymusiłem na Tobie wprowadzenia hasła podczas rejestracji. :smiley:

AMEN

P.S.
A wątek miał być o tym, czy inni też to widzą i czy ignorują ten problem (utraty maila i utraty dostępu przez OAuth), czy też nie.