Ultimo messaggio

giaesp

il 6 novembre 2007 alle 19:39

248 messaggi dal 30 gennaio 2004
Contributi
www.gianlucaesposito.it

Salve a tutti!
Ho un "piccolo" problema con la Forms Authentication di asp.net 2.0.
Ho impostato il db di modo che sia multiapplicazione.
Ho compilato il web.config nel modo seguente

<authentication mode="Forms">
<forms cookieless="UseUri"
defaultUrl="~/Default.aspx"
name=".ASPXAUTH"
path="/"
protection="All"
loginUrl="~/Default.aspx"
timeout="60"
slidingExpiration="true"
enableCrossAppRedirects="true"
requireSSL="true" />
</authentication>

/* Questo l'ho aggiunto dopo! */
<machineKey
validationKey="AutoGenerate"
decryptionKey="AutoGenerate"
validation="SHA1" />

Inoltre è attivo lo StateServer ed il tutto gira in modalità cookieless.

Cosa succede...
Un utente si logga normalmente e lavora autenticato. Ma se un nuovo utente si logga, il precedente perde l'autenticazione e viene buttato fuori dall'applicazione!
Praticamente ho creato senza volerlo una applicazione MONO UTENTE!!

Qualcuno di voi si è mai imbattuto in un problema del genere?

Grazie a tutti.

Gianluca
http://www.gianlucaesposito.it

Rispondi Quoting

Daniele Bochicchio

il 7 novembre 2007 alle 00:02

14.493 messaggi dal 31 agosto 1998
Contributi
daniele.aspitalia.com | Blog

giaesp wrote:

Praticamente ho creato senza volerlo una applicazione MONO UTENTE!!

c'è qualche proxy di mezzo? perchè la modalità cookieless usa il ticket nell'url ed un proxy potrebbe dare fastidio.

Daniele Bochicchio (ASPItalia.com)
I libri su HTML5, WP7, ASP.NET 4.0, VB 2010, C# 4, Entity Framework
Senior Software Architect @ 5DLabs.it

Rispondi Quoting

giaesp

il 7 novembre 2007 alle 12:55

248 messaggi dal 30 gennaio 2004
Contributi
www.gianlucaesposito.it

Si, le macchine di test utilizzano un proxy. Ma il problema si ripete anche sulle macchine di pubblicazione.

Spulciando su MSDN ho però trovato questo

Because a single default membership provider instance is used for all of the requests served by an HttpApplication object, you can have multiple requests executing concurrently and attempting to set the ApplicationName property value. The ApplicationName property is not thread safe for multiple writes, and changing the ApplicationName property value can result in unexpected behavior for multiple users of an application. We recommend that you avoid writing code to allow users to set the ApplicationName property unless you must. An example of an application where setting the ApplicationName property may be required is an administrative application that manages membership data for multiple applications. Such an application should be a single-user application and not a Web application.

http://msdn2.microsoft.com/en-us/library/system.web.security.sqlmembershipprovider.applicationname%28VS.80%29.aspx

E' esattamente il caso in cui mi trovo io...
C'è un modo per ovviare al problema?

Gianluca
http://www.gianlucaesposito.it

Rispondi Quoting

giaesp

il 7 novembre 2007 alle 14:04

248 messaggi dal 30 gennaio 2004
Contributi
www.gianlucaesposito.it

Sulla base della precedente raccomandazione ho trovato una soluzione poco elegante, ma efficace.
E' stata l'aggiunta di un provider per ogni applicazione presente nella tabella aspnet_applications a livello di web.config.

Ovvero ho aggiunto le seguenti righe nel web.config (duplicandole per ogni applicazione)

<add name="pippo.it"
type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
connectionStringName="DataConnectionString"
enablePasswordRetrieval="true"
enablePasswordReset="true"
requiresQuestionAndAnswer="false"
applicationName="pippo.it"
requiresUniqueEmail="false"
passwordFormat="Clear"
minRequiredPasswordLength="1"
minRequiredNonalphanumericCharacters="0"/>

Ho dovuto modificare la logica di autenticazione. Piuttosto che settare la proprietà ApplicationName della classe Membership, ho instanziato un MembershipProvider pescandolo tra quelli disponibili:

MembershipProvider membership = Membership.Providers["pippo.it"];

e quindi poi chiamare i metodi associati a membership.

Il problema è che il web.config ora deve essere aggiornato ogni volta che si crea un'applicazione nuova. Voi cosa fareste al mio posto?

Gianluca
http://www.gianlucaesposito.it

Rispondi Quoting

Daniele Bochicchio

il 7 novembre 2007 alle 15:37

14.493 messaggi dal 31 agosto 1998
Contributi
daniele.aspitalia.com | Blog

giaesp wrote:

Sulla base della precedente raccomandazione ho trovato una soluzione poco elegante, ma efficace.
E' stata l'aggiunta di un provider per ogni applicazione presente nella tabella aspnet_applications a livello di web.config.

la soluzione è quella di specificare sempre in maniera esplicita l'attributo applicationName, come specificato dalla documentazione, perchè di default prende il path correte e se hai x siti n root, sarà sempre lo stesso ("/").

Il problema è che il web.config ora deve essere aggiornato ogni volta che si crea un'applicazione nuova. Voi cosa fareste al mio posto?

io userei un database diviso per ogni applicazione e, ovviamente, un custom membership provider che semplicemente non preveda nemmeno lontanamente che applicazioni diverse vadano a scrivere e leggere nella stessa tabella dello stesso database.

Daniele Bochicchio (ASPItalia.com)
I libri su HTML5, WP7, ASP.NET 4.0, VB 2010, C# 4, Entity Framework
Senior Software Architect @ 5DLabs.it

Rispondi Quoting

Torna al forum | Feed RSS

ASPItalia.com non è responsabile per il contenuto dei messaggi presenti su questo servizio, non avendo nessun controllo sui messaggi postati nei propri forum, che rappresentano l'espressione del pensiero degli autori.

In primo piano