|
Jedno logovanje na 2 aplikacije
Ideja je imati 2 razlicite aplikacije (eventualno na razlicitim serverima) i obezbjediti jedan login. Recimo da su aplikacije phpBB i Joomla (lupam primjer), da pri registraciji oba prepravim registracione procedure i kad se registruje na jednom sistemu da se automatski registruje i na drugom. Znaci imam mogucnosti da prepravljam oba sistema jer su OS.
Kako bi izveli da kad se korisnik loguje na phpBB i klikne na nekom linku tog foruma na Joomla sajt, tj kad dodje na taj sajt da je vec ulogovan? Interesuju me ideje, programski cu se vec snaci. |
Zavisi za šta ti treba. Ako je za nešto kratkoročno ili nešto što ćeš samo ti koristiti onda igraj prljavo. Ako ti treba nešto ozbiljnije, što će koristiti više ljudi, što mora da bude integrisano sa postojećim sistemima (LDAP, postojeće aplikacije itd) onda tome treba pristupiti malo ozbiljnije.
Tema o kojoj razmišljam u skorije vreme je realizacija ovog drugog sistema (kako bi se activeCollba mogao integrisati u postojeća okruženja po firmama, bez potrebe da se hakuje kod ili da svaki zaposleni dobije još jedno korisničko ime i šifru koju treba pamtiti). Ovde objektno orijentisano programiranje i proširivost kao osnova razvoja rešenja znaju da budu od velikog značaja. Uglavnom, meni je ponajdraža ideja o jednog login sistemu kome svaka aplikacija ima pristup. Interfejs unutar samih aplikacija je prilično jednostavan i sve što je bitno je da ga svaka aplikacija implementira: * register($username, $password) - vraća novokreirani objekat User klase * autheticate($username, $password) - vraća objekat User klase ili baca exception * getUser($user_id) - vraća objekat User klase User klasa ima mogućnosti da sačuva svoja svojstva u taj centralni sistem. Kako ćeš realizovati samo skladištenje podataka, održavanje sesija itd itd itd - to je na centralizovanom sistemu da reši. Nije najjednostavnije moguće rešenje, ali je strašno fleksibilno jer su mehanizmi skladištenja i autentifikacije... zaključani. Aplikacije nemaju šta tu puno da razmišljaju. Btw, pogledaj kako je to rešeno kod Djanga. |
Hm, ako su te dve aplikacije na jednom domenu, onda neće biti problema (teoretski). Sad ne znam kako rade te aplikacije, ali u pincipu treba napraviti sledece:
- kad se korisnik registruje u jednoj aplikaciji, da se njegovi podatci upisu u drugu bazu (ako su na istom serveru ili je remote pristup bazi omogucen onda direktno u bazu, u suprotnom preko neke proxy skripte i slanja zahteva preko CURL-a ili tako nesto) - ako se zahteva aktivacija preko email-a, onda kad se aktivira nalog na jednom mestu, da se upise da je aktiviran i u drugoj aplikaciji na isti način kao u prethodnom koraku Ostaje samo login i logout: - ako su na istom serveru, treba iz jedne aplikacije pozvati funkciju za login iz druge (ako je moguće) ili napraviti ekvivalentnu (koja će postaviti odgovarajuće cookie-je ili sta već) - ako su na različitim serverima, i ako je u pitanju cookie-based login, onda obe aplikacije mogu biti na istom domenu (recimo prvaapp.domen.com i drugaapp.domen.com) pri čemu je najlakše napraviti ekvivalentnu funkciju za login ako je moguće ili pozvati drugu preko CURL-a, pokupiti cookie-je i proslediti ih klijentu... - ako su aplikacije na različitim domenima, nemogu se postaviti cookies za drugo domen sa ovog, tako da se u tom slučaju podatci o login-u moraju slati u sklopu URL-a kojim se pristupa drugom sajtu, a na tom drugom sajtu napraviti nešto što će takve URL-ove prihvatati, postavljati cookie i otvarati stvarnu stranu sa sadržajem. To je to u principu, nije nešto preterano komplikovano, ali nije ni jednostavno, tako da... |
Citat:
A sve radi vrlo transparentno, lokalni administrator moze da dodaje/brise korisnike kao i do tada, i prakticno ne mora nista da se menja u setupu sistema... Tu foru sam koristio za login aplikaciju u nekadasnjoj internet sali RCUBa, i fino je radila par godina, sekeretarica je kreirala i brisala accounte u postojecoj aplikaciji za to, nismo ni liniju koda morali da promenimo za integraciju... |
Da, ali je hack ;)
Ako uzmeš da je izvor autentifikacije proširiv (interfejs koji konkretni izvori moraju da implementiraju ili apstraktna klasa koju izvori treba da naslede - glasam za ovo drugo) onda lako možeš napraviti pop3 izvor - jedna klasa, korisnik samo kaže sistemu da koristi upravo nju u config.php fajlu i on je dobar. Šta dobijaš kasnije? Mnogo... Dođe neko i integriše ga sa nekim postojećim ili novim metodima autentifikacije, napravi bolje skladište podataka i ponudi ga korisnicima itd itd. Nađe se recimo neko i napravi da možeš da koristiš Basecamp accounte za logovanje (jes da ne vidim preteranu poentu u tome, ali naći će se neko ko će to napraviti iz proste zafrkancije) Jednostavno, možeš da radiš šta god ti padne na pamet. Nivo kompleksnosti rešenja je povećan, ali je fleksibilnost dovedena do te mere da više ne moraš previše da brineš o tome i na svaki feature request možeš da kažeš: Pera je to već napravio, evo ti link za download ili evo ti uputsvo pa integriši (ili pak najbolje: moj hourly rete je toliko, možemo da pričamo :D ). A što se konkretnog slučaja tiče, kao što rekoh: igraj prljavo, hackuj skripte zekica rekao i ne bi trebalo da bude problema. Sranje je samo što modovi nikad nisu zvainično podržani i moraš sam da se brineš o njima prilikom upgradea. |
Hvala svima na odgovorima. Ono sto je meni problem (mislim, otezava posao) jer da je jedna aplikacija neki web store napisan u ColdFusion i radi na MS SQL serveru. Znaci... totalno 2 drugacije tehnologije i baze i 2 masine i ... malo toga zajednickog.
Oki, interesuje me malo login sistem koristenjem sesija (vidio sam da ga koriste i Joomla i phpBB, vjerovatno jos tona php OS rjesenja). Koliko sam shvatio, kad se korisnik konektuje na sajt, u tabeli session se doda red sa session_id (generisano ne znam kako, nije ni vazno), i taj isti session bi trebao da bude kod usera u cookie-u. Kazem 'trebao bi' jer sam prateci malo Joomla-u uvidio da nije, mada moram jos malo iskontrolisati (ocistiti cookije i pratiti). Zatim, taj korisnik tako razgleda sajt ovo, ono... kad odluci da se uloguje, taj red u tabeli dobije popunjeno polje 'logged' sa recimo username-om i slicno i onda CMS zna da je korisnik logovan i na osnovu toga se i ponasa. Pitanja: - Kako radi mehanizam za brisanje viska redova, tj sessija koje su istekle? - Da li to znaci da ja mogu sve to uraditi preko pristupa bazi na ovaj nacin: * korisnik se loguje na jednu aplikaciju - ispravno * u bazu druge aplikacije dodam red u session sa cak istim session varijablom * u taj red, u drugoj bazi promjenim polje logged u 'YES' ili sta je vec potrebno kako bi oznacio ulogovanog korisnika * korisniku (buduci da je rijec o drugom domenu) posaljem cookie koji koristi druga aplikacija. Hm.. ako ima kakvih clanaka na tu temu ili kakav help, dobro bi doshao :) hvala jos jednom |
ne bi li ti bilo jednostavnije:
korisnik dolazi na jednu aplikaciju. aplikacija provjerava je li logiran u njenoj bazi? ako je, sve pet, ako nije, provjerava je li logiran u drugoj bazi? ako je, opet sve pet. ako nije, goni ga na svoju login stranu. istu stvar radi i druga aplikacija. |
Citat:
|
Citat:
znaci, svaka cita svoj cookie i zapis za tog usera u session tabeli druge baze. ako u nijednom ne nadje stanje=logirano -> salje na login skriptu. ako pak u ijednom nadje stanje=logirano -> i u svoju bazu pise user_id=logiran. Edit: phpBB radi nesto takvo |
Citat:
|
| Vreme je GMT +2. Trenutno vreme je 20:26. |
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.