Καλησπέρα!

Κατά το authentication δημιουργώ ένα cookie (μέσω του FormsAuthentication), αλλά και ένα Session στο οποίο κρατάω μια class User, με πληροφορίες για τον user.
Είναι σωστή τεχνική το να έχω και Session, αλλά και Cookie?

Επίσης το authentication ή authorization, μπορώ να το ελέγξω με δύο τρόπους.
Μπορώ να ελέγχω αν υπάρχει το session. Αν υπάρχει, ο χρήστης έχει γίνει από πριν authenticated, οπότε δεν τον πετάει στην Logon.aspx.
Ο άλλος τρόπος είναι μέ το cookie (πχ μέςω του Application_AuthenticateRequest στο global.asax).

Ποιός είναι ο καλύτερος ή πιο σωστός τρόπος?

Νομίζω πως το Session για αυτήν την χρήση είναι περιτό.

Αφου αν έχεις ορίσει <authorization> rule στο web.config θα κάνει check η ASP.NET

σε κάθε request σελίδας αν έχει γίνει authentication. Επίσης αν θέλεις να δείς για κάποιο άλλο λόγο

αν ο χρήστης είναι authenticated δες την User.Identity.

 

Όσο για το cookie είναι για το αν ο χρήστης θα πρέπει να ξανακάνει login την επόμενη φορά ή αλλιώς

ανάμεσα σε διαφορετικά browser sessions. Δεν περιέχει ευαίσθητες πληροφορίες. Μόνο το username νομίζω.

Αν κάποιος browser έχει απενεργοποιημένα τα cookies, απλά θα πρέπει να ξανακάνει Login σεν κάθε νέο session.

 

 

---

Το session το χρειάζομαι γιατί θέλω κάπου να κρατάω το object user, που περιέχει πληροφορίες για τον χρήστη.

Το κριτήριο για το αν ο χρήστης έχει κάνει login πρέπει να είναι όντως το cookie. Το object user το θέλεις κάπου στη μνήμη για να μην το αναζητάς από κάποια βάση κάθε φορά. Σωστά;

Η λύση αυτή είναι κυρίως η Server.Cache. Τα session variables όντως είναι και αυτά μια λύση αλλά για λόγους scalability όταν μπορούμε τα αποφεύγουμε. Όχι ότι πέθαναν βέβαια. Αν κάνεις κάτι όντως μικρό, proof of concept κλπ δεν είναι και έγκλημα.

---

Dimitris Papadimitriou Software Development Professional

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

gspiros:

Το session το χρειάζομαι γιατί θέλω κάπου να κρατάω το object user, που περιέχει πληροφορίες για τον χρήστη.

Το ASP.NET user object δεν χρειάζεται να το cachάρεις - μπορείς να το ανακτάς σε κάθε σελίδα που φορτώνεται. Αν έχεις έξτρα πληροφορίες, μπορείς να χρησιμοποιήσεις το profiling σύστημα του ASP.NET για να τα αποθηκεύσεις και να τα ανακτάς με την βοήθεια του User object. Αν το profiling σύστημα δεν είναι αρκετό για αυτό που κάνεις, και σε συνδυασμό όταν χρειάζεσαι custom coοkies, θα πρότεινα να κάνεις inherit το ASP User object και να υλοποιήσεις επάνω σε αυτό και το μηχανισμό του, το δικό σου - έτσι κρατάς ότι υπάρχει, αλλά προσθέτεις και τα δικά σου...

 

George J.

---

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

George J. Capnias:

Το ASP.NET user object δεν χρειάζεται να το cachάρεις - μπορείς να το ανακτάς σε κάθε σελίδα που φορτώνεται. Αν έχεις έξτρα πληροφορίες, μπορείς να χρησιμοποιήσεις το profiling σύστημα του ASP.NET για να τα αποθηκεύσεις και να τα ανακτάς με την βοήθεια του User object. Αν το profiling σύστημα δεν είναι αρκετό για αυτό που κάνεις, και σε συνδυασμό όταν χρειάζεσαι custom coοkies, θα πρότεινα να κάνεις inherit το ASP User object και να υλοποιήσεις επάνω σε αυτό και το μηχανισμό του, το δικό σου - έτσι κρατάς ότι υπάρχει, αλλά προσθέτεις και τα δικά σου...

 

Δεν θέλω να χρησιμοποιήσω το Profiling.
Tο να ανακτώ το custom object user κάθε φορά που φορτώνεται μια σελίδα, δεν θα είναι περιττό overhead?

Το object αυτό όντως το χρειάζομαι για να μην το ανακτώ κάθε φορά από την βάση.

Για να καταλάβω, σχετικά με το Login.
Αν το cookie δεν υπάρχει ο χρήστης θεωρείται signed out, σωστά?
Αν όμως υπάρχει το Cache["user"] ή το Session["user"]?
Τότε θα μπορούσαμε να θεωρήσουμε τον user logged on?

Στην περίπτωση που υπάρχει το cookie (τον θεωρούμε logged on), αλλά δεν υπάρχει το Cache ή το Session???
Απλά τα ανακτούμε πάλι από την βάση?

Τώρα που το σκέφτομαι, το Cache δεν είναι μεταβλητή του Application?
Αυτό δεν σημαίνει ότι δεν μπορεί να χρησιμοποιηθεί για ένα custom object user, αφού κάθε user που κάνει log in, θα έχει διαφορετικές πληροφορίες λογαριασμού????

gspiros:

Δεν θέλω να χρησιμοποιήσω το Profiling.
Tο να ανακτώ το custom object user κάθε φορά που φορτώνεται μια σελίδα, δεν θα είναι περιττό overhead?

Το object αυτό όντως το χρειάζομαι για να μην το ανακτώ κάθε φορά από την βάση.

Για να καταλάβω, σχετικά με το Login.
Αν το cookie δεν υπάρχει ο χρήστης θεωρείται signed out, σωστά?
Αν όμως υπάρχει το Cache["user"] ή το Session["user"]?
Τότε θα μπορούσαμε να θεωρήσουμε τον user logged on?

Στην περίπτωση που υπάρχει το cookie (τον θεωρούμε logged on), αλλά δεν υπάρχει το Cache ή το Session???
Απλά τα ανακτούμε πάλι από την βάση?

Να τα πάρουμε από την αρχή - με το που logάρει ένας χρήστης το User Object του (MembershipUser) cachάρεται, θέλεις δεν θέλεις, μέσα στο HttpContext (HttpContext.Current.User), οπότε δεν το φορτώνεις κάθε φορά. Τα cookies έχουν φτιαχτεί, και αναλόγως πως έχεις setάρει το membership provider, θα κάνουν exprire, κτλ. Για να δεις αν κάποιος είναι συνδεδεμένος η όχι, το μόνο που έχεις να κάνεις είναι να δεις αν το HttpContext.Current.User.IsInRole() έχει το default role που έχουν οι χρήστες του site.

To Profiling σύστημα είναι κάτι διαφορετικό - είναι έξτρα στο Membership και δεν είναι υποχρεωτικό να το έχεις. Είναι έξτρα στατικές πληροφορίες. Δεν χρησιμοποιούνται συνέχεια, πιθανώς οι μόνες στιγμές που διαβάζεις κάποιες αυτές τις πληροφορίες είναι όταν ο ίδιος ο χρήστης ή κάποιος administrator κοιτάει το profile του χρήστη. Αν εσύ προσπαθείς να υλοποιήσεις, ότι κάποια features του site να ενεργοποιούνται ή απενεργοποιούνται ανάλογα μια ιδιότητας του profile, είναι λάθος υλοποίηση. Μια τέτοια υλοποίηση θα πρέπει να γίνει βάση ρόλων, που περιέχονται ήδη στο Membership.

Βέβαια όπως είπα και παραπάνω, η έσχατη περίπτωση είναι να φτιάξεις δικό μου membership provider. Οπότε μπορείς να κάνεις extend τις μεθόδους και να προσθέσεις ιδιότητες στο αντικείμενο καθώς και να υλοποιήσεις τις μεθόδους του κατά τις ανάγκες σου.

 

George J.

---

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

Το User.IsInRole() δεν δουλεύει απο όσο ξέρω σε Forms Authentication.Μονο σε Windows Authentication.

Με το User.Identity.Name π.χ μπορει να πάρει το Username, User.IsAuthenticated property

αν είναι authenticated.

---

gtas:

Το User.IsInRole() δεν δουλεύει απο όσο ξέρω σε Forms Authentication.Μονο σε Windows Authentication.

Με το User.Identity.Name π.χ μπορει να πάρει το Username, User.IsAuthenticated property

αν είναι authenticated.

Αν φτιάξεις roles μέσα από το administration tool για το ASP.NET Membership, τότε θα δουλέψουν και στο Form Authentication. Το dotNETZone χρησιμοποιεί αυτό το χαρακτηριστικό...

Το IsAuthenticated() δεν είναι κακή προσέγγιση του προβλήματος αν κάποιος είναι logαρισμένος. Από την άλλη, τα δικαιώματα πρόσβασης μέσα στο web.config και η χρήση ρόλων, είναι πολύ "καθαρή προσέγγιση" στην λύση του προβλήματος Authorization...

 

George J.

---

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

Δεν το ήξερα αυτό. Νόμιζα ότι είναι μόνο για SQL Membership. Θα το κοιτάξω καλύτερα το Administration Tool αμέσως ;)

---

George J. Capnias:

Να τα πάρουμε από την αρχή - με το που logάρει ένας χρήστης το User Object του (MembershipUser) cachάρεται, θέλεις δεν θέλεις, μέσα στο HttpContext (HttpContext.Current.User), οπότε δεν το φορτώνεις κάθε φορά. Τα cookies έχουν φτιαχτεί, και αναλόγως πως έχεις setάρει το membership provider, θα κάνουν exprire, κτλ. Για να δεις αν κάποιος είναι συνδεδεμένος η όχι, το μόνο που έχεις να κάνεις είναι να δεις αν το HttpContext.Current.User.IsInRole() έχει το default role που έχουν οι χρήστες του site.

To Profiling σύστημα είναι κάτι διαφορετικό - είναι έξτρα στο Membership και δεν είναι υποχρεωτικό να το έχεις. Είναι έξτρα στατικές πληροφορίες. Δεν χρησιμοποιούνται συνέχεια, πιθανώς οι μόνες στιγμές που διαβάζεις κάποιες αυτές τις πληροφορίες είναι όταν ο ίδιος ο χρήστης ή κάποιος administrator κοιτάει το profile του χρήστη. Αν εσύ προσπαθείς να υλοποιήσεις, ότι κάποια features του site να ενεργοποιούνται ή απενεργοποιούνται ανάλογα μια ιδιότητας του profile, είναι λάθος υλοποίηση. Μια τέτοια υλοποίηση θα πρέπει να γίνει βάση ρόλων, που περιέχονται ήδη στο Membership.

Βέβαια όπως είπα και παραπάνω, η έσχατη περίπτωση είναι να φτιάξεις δικό μου membership provider. Οπότε μπορείς να κάνεις extend τις μεθόδους και να προσθέσεις ιδιότητες στο αντικείμενο καθώς και να υλοποιήσεις τις μεθόδους του κατά τις ανάγκες σου.

 

George J.

Είσαι σίγουρος ότι το User object του MembershipUser cachάρεται ΠΑΝΤΑ στο Current.User?

Ο κώδικας που χρησιμοποιώ για το Authentication είναι ο παρακάτω (βρίσκεται μέσα στο Global.asax).
Όπως βλέπεις στο τέλος, κάνω:
Context.User = principal;

protected void Application_AuthenticateRequest(Object sender, EventArgs e)
{
// Extract the forms authentication cookie
string cookieName = FormsAuthentication.FormsCookieName;
HttpCookie authCookie = Context.Request.Cookies[cookieName];
if(null == authCookie)
{
// There is no authentication cookie.
return;
}
FormsAuthenticationTicket authTicket = null;
try
{
authTicket = FormsAuthentication.Decrypt(authCookie.Value);
}
catch(Exception ex)
{
// Log exception details (omitted for simplicity)
return;
}
if (null == authTicket)
{
// Cookie failed to decrypt.
return;
}
// When the ticket was created, the UserData property was assigned a
// pipe delimited string of role names.
string[] roles = authTicket.UserData.Split(new char[]{'|'});
// Create an Identity object
FormsIdentity id = new FormsIdentity( authTicket );
// This principal will flow throughout the request.
GenericPrincipal principal = new GenericPrincipal(id, roles);
// Attach the new principal object to the current HttpContext object
Context.User = principal;
}

Σε αυτήν την περίπτωση, που και πως δημιουργείται το MembershipUser και φορτώνεται στο HttpContext???

gspiros:

Είσαι σίγουρος ότι το User object του MembershipUser cachάρεται ΠΑΝΤΑ στο Current.User?

Ο κώδικας που χρησιμοποιώ για το Authentication είναι ο παρακάτω (βρίσκεται μέσα στο Global.asax).
Όπως βλέπεις στο τέλος, κάνω:
Context.User = principal;

protected void Application_AuthenticateRequest(Object sender, EventArgs e)
{
// Extract the forms authentication cookie
string cookieName = FormsAuthentication.FormsCookieName;
HttpCookie authCookie = Context.Request.Cookies[cookieName];
if(null == authCookie)
{
// There is no authentication cookie.
return;
}
FormsAuthenticationTicket authTicket = null;
try
{
authTicket = FormsAuthentication.Decrypt(authCookie.Value);
}
catch(Exception ex)
{
// Log exception details (omitted for simplicity)
return;
}
if (null == authTicket)
{
// Cookie failed to decrypt.
return;
}
// When the ticket was created, the UserData property was assigned a
// pipe delimited string of role names.
string[] roles = authTicket.UserData.Split(new char[]{'|'});
// Create an Identity object
FormsIdentity id = new FormsIdentity( authTicket );
// This principal will flow throughout the request.
GenericPrincipal principal = new GenericPrincipal(id, roles);
// Attach the new principal object to the current HttpContext object
Context.User = principal;
}

Σε αυτήν την περίπτωση, που και πως δημιουργείται το MembershipUser και φορτώνεται στο HttpContext???

Όχι, δεν το cachάρει. Το MembershipUser object μπορείς να το πάρεις με το Membership.GetUser() από το HttpContext.Current.User.

Τι πληροφορίες έχεις στο profile του χρήστη που θες να τις έχεις συνεχώς διαθέσιμες;

 

George J.

---

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

Δεν κατάλαβα πως θα πάρω το MembershipUser από το Current.User...
Πως όμως μπορείς να πάρεις ένα IPrincipal (Current.User) Από την μέθοδο Membership.GetUser() που επιστρέφει MembershipUser?????
Δεν θέλω να χρησιμοποιήσω Membership ή Profile!!!

Δεν θέλω να κάνω κάτι συγκεκριμένο, απλά ψάχνω!
Θα μπορούσε όμως κάποιο customUser να κρατά πληροφορίες όπως ηλικία, fullname κτλ, τα οποία χρειάζονται συνέχεια όσο ο χρήστης είναι loggedon.

Το customUser θα κρατιέται σε Session.
Δεν είναι σωστή διαδικασία αυτή?

Τέλος, μια ακόμα ερώτηση.
Αν τελικά κρατάω κάποιες πληροφορίες του user σε Session, χρειάζεται να κάνω το authentication βάση του cookie που είχα περιγράψει νωρίτερα???
Δεν μπορώ απλά να κάνω authentication βάση του Session?

Η αρχική μου απορία ήταν αυτή!
Ποιά είναι καλύτερη μέθοδος για authentication και authorization?
Βάση του Cookie ή του Session?

Mπορώ να ρωτήσω κάτι?
Χρησιμοποιείς SqlMemberShipProvider?

---

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