gspiros:

Όχι δεν χρησιμοποιώ.

Αυτό δεν είναι σωστό: Μέσα στο machine.config σου λέει ότι χρησιμοποιείς. Μπορεί να μην το καταλαβαίνεις, αλλά το ASP.NET τα setάρει όλα αυτά για σένα, η σωστότερα τα έχει ήδη σεταρισμένα για σένα.

To IPrinciple φτιάχνεται από το Authentication Cookie, που περιέχει όνομα και ρόλους του χρήστη. Το Membership.GetUser() χρησιμοποιώντας το UserName από το HttpContext.Current.User μπορεί να κάνει retrieve τα στοιχεία του χρήστη που αποθηκεύει το ASP.NET MembershipProvider. Στην ουσία, το SqlMembershipProvider είναι setαρισμένο σαν default, και εσύ αυτό που έχεις να κάνεις είναι να βάλεις μέσα στην βάση που δείχνει το default connection string του machine.config τα απαραίτητα tables, views και store procedures για να παίξει.

Ο SqlMembership είναι μια υλοποίηση του MembershipProvider. Άλλη είναι το ActiveDirectoryMembershipProvider. Κάθε data provider (MySql, Oracle) έχει μια αντίστοιχη υλοποίηση του MembershipProvider. Υπάρχουν και άλλοι providers για να παίξουν με OpenID, LDAP, αλλά και .NET Passport, FacebookConnect κοκ...

Το Authorization μέσα στην εφαρμογή καλό είναι να γίνεται με ρόλους, γιατί δεν χρειάζονται ούτε πρόσβαση μέσα στο MemberUser object - δεν σε ενδιαφέρει ποιος θα είναι ο membership provider που θα έχεις - , ούτε μέσα στο Profiling υποσύστημα. Αυτό δεν σημαίνει ότι δεν κρατάς λογαριασμούς χρηστών, και δεν χρειάζεσαι το Membership - πρέπει να υπάρχει κάποια βάση (rdbms, xml, webservice) - το χρειάζεσαι, απλά το authentication γίνεται με διαφορετικό τρόπο κάθε φορά.

 

George J.

---

George J. Capnias: Χειροπρακτικός Υπολογιστών, Ύψιστος Γκουράρχης της Κουμπουτερολογίας w: capnias.org, t: @gcapnias, l: gr.linkedin.com/in/gcapnias

Προφανώς τότε έχεις κάνει Extend το Provider Model από το MembershipProvider και έχεις υλοποιήση το δικό σου?
Που αποθηκεύεις τους χρήστες? web.config? σε δικιά σου βάση? στις ASP.NET Provider databases που δημιούργησες
με την aspnet_regsql command line tool?

Μήπως θέλεις απλά να δημιουργήσεις ένα instance, MembershipUser mu = new MembershipUser(params)
και να αναφέρεσαι σε αυτό το Οbject μέσω SessionState?!

Νομίζω πως κάτι σου λείπει anyway, ή δεν έχει γίνει σωστά.

Η από ότι καταλαβαίνω τελικά χρησιμοποιείς Forms Authentication αλλά κανένα MembershipProvider.

---

Να τα πάρουμε λίγο τα πράγματα από την αρχή...
Δεν χρησιμοποιώ Membership, εννοώ ότι δεν έχω κάποια κλάση που να κληρονομεί από την Membership!

Έχω μια βάση που κρατά username,password, κτλ, και τέλος τις σελίδες που ο χρήστης μπορεί να επισκεφθεί.
Ο authorization δηλαδή δεν θα γίνεται από το web.config, αλλά από τις πληροφορίες της βάσης για τον κάθε user.
Θέλω λοιπόν να κρατώ σε Session το custom object user!

Η ερώτησή μου τώρα είναι η εξής:
Το authentication καλό είναι να γίνεται με cookie ή με το session που θα κρατάω έτσι και αλλιώς???
Αν θέλω να έχω persistent login (remember me), τότε πρέπει να χρησιμοποιήσω cookies (όπως είχα περιγράψει σε παλαιότερο post) έτσι και αλλιώς ή μπορεί να γίνει και απλά με το Session????
Τέλος, για να υλοποιήσω αυτό που περιέγραψα (να κρατάω τις επιτρεπτές σελίδες στην βάση), υπάρχει καλύτερος τρόπος???

gspiros:

Να τα πάρουμε λίγο τα πράγματα από την αρχή...
Δεν χρησιμοποιώ Membership, εννοώ ότι δεν έχω κάποια κλάση που να κληρονομεί από την Membership!

Έχω μια βάση που κρατά username,password, κτλ, και τέλος τις σελίδες που ο χρήστης μπορεί να επισκεφθεί.
Ο authorization δηλαδή δεν θα γίνεται από το web.config, αλλά από τις πληροφορίες της βάσης για τον κάθε user.
Θέλω λοιπόν να κρατώ σε Session το custom object user!

Η ερώτησή μου τώρα είναι η εξής:
Το authentication καλό είναι να γίνεται με cookie ή με το session που θα κρατάω έτσι και αλλιώς???
Αν θέλω να έχω persistent login (remember me), τότε πρέπει να χρησιμοποιήσω cookies (όπως είχα περιγράψει σε παλαιότερο post) έτσι και αλλιώς ή μπορεί να γίνει και απλά με το Session????
Τέλος, για να υλοποιήσω αυτό που περιέγραψα (να κρατάω τις επιτρεπτές σελίδες στην βάση), υπάρχει καλύτερος τρόπος???

Η λύση που έχεις δώσεις στο πρόβλημά, δεν είναι η "περπατημένη" - δηλαδή δεν έχεις κάνει:

• χρήση της ASP.NET membership database,
• χρήση των έτοιμων controls,
• χρήση roles σε συνδυασμό με web.config για να "κλειδώσεις" την εφαρμογή σου.

Το να αξιολογήσει κάποιος αυτό που έκανες, δεν έχει νόημα - δεν μπορείς να πει ότι είναι σωστό ή λάθος. Προφανώς, για να το υλοποίησες έτσι, είχες τους λόγους σου, που δεν είμαστε σε θέση να γνωρίζουμε.

To session δεν μπορεί να κρατηθεί μεταξύ διαδοχικών επισκέψεων του χρήστη - ο τρόπος να κάνεις "remember me" είναι το cookie.

Να υλοποιήσεις τις "επιτρεπτές σελίδες" μέσα στην βάση - κάπου έχασα αυτό το κομμάτι μέσα στην συζήτηση - είναι υπερβατικό στο σχεδιασμό του ASP.NET authentication/authorization σε συνδυασμό με το Membership/Profiling. Δηλαδή, δεν το έχουν σχεδιάσει για να λειτουργήσει έτσι. Άρα καλύτερος τρόπος υλοποίησης σε σχέση με τι; Δεν έχουμε παρόμοια πράγματα να συγκρίνουμε...

 

George J.

---

George J. Capnias: Χειροπρακτικός Υπολογιστών, Ύψιστος Γκουράρχης της Κουμπουτερολογίας w: capnias.org, t: @gcapnias, l: gr.linkedin.com/in/gcapnias

Καλύτερος τρόπος είναι να χρησιμοποιήσεις τους μηχανισμούς του ASP.NET αντί να φτιάξεις τους δικούς σου. Είναι απλά κακή ιδέα να ξανα-ανακαλύπτεις τον τροχό, και να τον κάνεις και ελαφρώς οβάλ-προς-τετράγωνο!

Πέρα από το προφανές, γιατί να φτιάξεις κάτι που υπάρχει ήδη έτοιμο και ασφαλές,  φτιάχνοντας τη δική σου λύση χάνεις και κάποια πλεονεκτήματα που δεν τα έχεις σκεφτεί. Για παράδειγμα, όλες οι εφαρμογές ASP.NET σε ένα domain μπορούν να χρησιμοποιήσουν το ίδιο authentication cookie και έτσι να μην απαιτείται ξεχωριστό login σε κάθε εφαρμογή.

Σκέψου το εξής. Ο μηχανισμός του ASP.NET φροντίζει για την αποθήκευση σε όποια βάση του πεις, επιτρέπει τη χρήση profile, τον ορισμό ρόλων,  αναλαμβάνει αυτόματα το caching, αναλαμβάνει το encryption των passwords, μπορεί κατ' επιλογή να επιτρέψει password recovery, password reset ή τίποτε από τα δύο. Μπορείς να τον επεκτείνεις εύκολα φτιάχνοντας τους δικούς σου Membership και Role providers, για να τραβήξεις π.χ. τους ρόλους των χρηστών από μία άλλη εφαρμογή, βάση ή ακόμα και άλλη εταιρεία.

 Τί θα κερδίσεις φτιάχνοντας τα όλα αυτά από την αρχή?

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos

Αν θέλω να χειρίζομαι τις επιτρεπτές σελίδες κάθε χρήστη μέσα από μια admin σελίδα?
Αυτό δεν μπορώ να το κάνω αν οι ρόλοι αποθηκεύονται στο web.config!
Πως θα αλλάξω τα allow και deny roles των authentication και authorization?

gspiros:

Αν θέλω να χειρίζομαι τις επιτρεπτές σελίδες κάθε χρήστη μέσα από μια admin σελίδα?
Αυτό δεν μπορώ να το κάνω αν οι ρόλοι αποθηκεύονται στο web.config!
Πως θα αλλάξω τα allow και deny roles των authentication και authorization?

Δεν το κατάλαβες σωστά:

• Μέσα στο web.config έχεις τους ρόλους και τα paths που τους επιτρέπονται να πηγαίνουν.
• Μέσα από το administration του site σου, μοιράζεις τους ρόλους στους χρήστες σου και αυτόματα αποκτούν πρόσβαση.

Δυναμικοί ρόλοι, που ορίζονται on-the-fly και μαζί τα paths που μπορούν να έχουν πρόσβαση, και στην συνέχεια διανέμονται στους χρήστες, είναι ένα μη αληθινό σενάριο - είναι σαν να λες ότι δεν ξέρεις τι θα κάνει η εφαρμογή σου, και θέλεις να το ανακαλύψεις παίζοντας με τους χρήστες της...

 

George J.

---

George J. Capnias: Χειροπρακτικός Υπολογιστών, Ύψιστος Γκουράρχης της Κουμπουτερολογίας w: capnias.org, t: @gcapnias, l: gr.linkedin.com/in/gcapnias

Ξεκίνα απο εδώ --> http://www.4guysfromrolla.com/articles/120705-1.aspx

και εδώ --> http://msdn.microsoft.com/en-us/library/ms998347.aspx

Η αλήθεια είναι ότι είναι αρκετά...κι εγώ ακόμα δεν τα ξεκαθάρισα πλήρως...αλλα θα εξακριβώσεις σχεδόν όλα.

Από εκεί και πέρα ... practise.

---

Ο Role Provider δεν είναι υποχρεωτικό να διαβάζει τους ρόλους από το Web.config. Άσε που διαφωνώ με το Γιώργο, είναι εξαιρετικά συχνό και μάλλον πιο πιθανό το σενάριο να ΜΗΝ ξέρεις τους ρόλους εκ των προτέρων. Αν βασιζόμουν στη δική μου εμπειρία, θα έλεγα ότι δεν έχω βρει ποτέ εφαρμογή που να αρκείται στους ρόλους μέσα στο web.config, αλλά αυτό είναι προσωπική εμπειρία. Σε μια εφαρμογή που φτιάχνεται μία φορά για ένα μόνο πελάτη, μπορεί να ξέρεις τους ρόλους εκ των προτέρων. Αν η εφαρμογή πρέπει να προσαρμόζεται σε διαφορετικούς πελάτες όμως, οι ρόλοι πρέπει να αποθηκεύονται στη βάση.

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos

gtas:

Ξεκίνα απο εδώ --> http://www.4guysfromrolla.com/articles/120705-1.aspx

και εδώ --> http://msdn.microsoft.com/en-us/library/ms998347.aspx

Η αλήθεια είναι ότι είναι αρκετά...κι εγώ ακόμα δεν τα ξεκαθάρισα πλήρως...αλλα θα εξακριβώσεις σχεδόν όλα.

Από εκεί και πέρα ... practise.

Το Membership το γνωρίζω και το έχω χρησιμοποιήσει καλαιότερα, αλλά αυτήν την φορά δεν θέλω να το χρησιμοποιήσω!
Όπως σας είπα ψάχνω και ήμουν περίεργος το πως θα υλοποιήσω αυτό που έχω περιγράψει.

gspiros:

Να τα πάρουμε λίγο τα πράγματα από την αρχή...
Δεν χρησιμοποιώ Membership, εννοώ ότι δεν έχω κάποια κλάση που να κληρονομεί από την Membership!

Έχω μια βάση που κρατά username,password, κτλ, και τέλος τις σελίδες που ο χρήστης μπορεί να επισκεφθεί.
Ο authorization δηλαδή δεν θα γίνεται από το web.config, αλλά από τις πληροφορίες της βάσης για τον κάθε user.
Θέλω λοιπόν να κρατώ σε Session το custom object user!

Η ερώτησή μου τώρα είναι η εξής:
Το authentication καλό είναι να γίνεται με cookie ή με το session που θα κρατάω έτσι και αλλιώς???
Αν θέλω να έχω persistent login (remember me), τότε πρέπει να χρησιμοποιήσω cookies (όπως είχα περιγράψει σε παλαιότερο post) έτσι και αλλιώς ή μπορεί να γίνει και απλά με το Session????
Τέλος, για να υλοποιήσω αυτό που περιέγραψα (να κρατάω τις επιτρεπτές σελίδες στην βάση), υπάρχει καλύτερος τρόπος???

Όπως ήδη αναφέρθηκε παραπάνω, για persistent login χρειάζεσαι οπωσδήποτε κουλουράκι.

Αν θέλεις να αποθηκεύσεις κάπου ένα custom object (στην περίπτωσή σου τον user) εγώ προτείνω το Cache object, γιατί είναι λίγο πιο scalable από το Session. Εκεί μπορείς να ορίσεις πόση ώρα θα μείνει το αντικείμενο στην cache και μάλιστα πόση ώρα μετά την τελευταία χρήση.

Τέλος προτείνω κι εγώ να κάνεις μια υλοποίηση του MembershipProvider (δεν είναι τόσο δύσκολο). Αν πάλι υπάρχουν λόγοι, όχι τεχνικού χαρακτήρα, που σε αποτρέπουν, συνέχισε έτσι.

---

Dimitris Papadimitriou Software Development Professional

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Διαβάστε επίσης τους όρους χρήσης.

Το Cache δεν είναι μια application μεταβλητή?
Μπορεί να χρησιμοποιηθεί για να αποθηκεύει πληροφορίες διαφορετικές για κάθε session?

Θέλω να πω ότι αν αποθηκεύσω τον user1 σε Cache, ο user2 δεν θα έχει πρόσβαση στα Στις ίδιες πληροφορίες (object user1)???

gspiros:

Το Cache δεν είναι μια application μεταβλητή?
Μπορεί να χρησιμοποιηθεί για να αποθηκεύει πληροφορίες διαφορετικές για κάθε session?

Θέλω να πω ότι αν αποθηκεύσω τον user1 σε Cache, ο user2 δεν θα έχει πρόσβαση στα Στις ίδιες πληροφορίες (object user1)???

Κοίταξε, κάποια πράγματα πρέπει να τα διαβάσεις. Δεν μπορώ να σου εξηγήσω με ερωτήσεις και απαντήσεις πως λειτουργεί η Cache στην asp.net. Ρίξε μια ματιά εδώ http://quickstarts.asp.net/QuickStartv20/default.aspx.

Η γενική ιδέα που προσπαθούν να σου εξηγήσουν τα παιδιά είναι η εξής:

1) Για authentication στην asp.net χρησιμοποιείται ο membership provider

2) Αν δεν θέλεις να καλείς συνέχεια την βάση γιατί κάτι το χρησιμοποιείς συχνά η asp.net έχει την Cache

Προφανώς τα ίδια πράγματα μπορείς να τα υλοποιήσεις με πολλούς τρόπους. Όσο πιο κοντά είσαι στους προτεινόμενους, τόσο λιγότερο κώδικα θα γράψεις, με αποτέλεσμα η λύση σου να είναι πιο εύκολο να συντηρηθεί και να επεκταθεί από σένα ή άλλους developers. Αν δεν σου αρέσουν οι έτοιμες λύσεις και θέλεις να κάνεις innovation πρέπει να σκεφτείς αν μπορείς και να πάρεις τα ρίσκα σου.

---

Dimitris Papadimitriou Software Development Professional

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Διαβάστε επίσης τους όρους χρήσης.

Ευχαριστώ για τις πληροφορίες παιδιά, ήταν πολύτιμες!