2012-02-18 10 views
1

ASP.NETは、現在、私のWebアプリケーションは、以下の構成(web.configファイル)と共有サーバー(asphostcentral)でホストされています共有サーバーを使用してセッションを維持する方法/ MVC

<authentication mode="Forms"> 
    <forms loginUrl="~/Account/LogOn" timeout="2880" cookieless="UseCookies"> 

しばらくすると、セッションの有効期限が切れると、ユーザーはにリダイレクトされますログインページを開き、資格情報を再度入力する必要があります。

私はサポートから受け取った答えは次のとおりです。

これは共有サーバーであるとして、あなたがセッション状態を使用しないことをお勧めします。 代わりに、cookieを使用してください。あなたがクッキーをプログラミングする方法は、非常に非常にですが、実装とは異なり、セッションに似た と似ています。

共有サーバーでは、 がサイトのセッションに影響を与える可能性のある他のサイトがサーバーにあります。

誰でもこれを支援できますか?サポートチームによって提供されるソリューションの実装方法を教えてください。

+0

あなたの答えに感謝します。これが解決策でした:http://geekfreeq.ventaur.com/aspnet-remember-me-option-forms-authentication-not-working/ machineKey inside web.configが解決されました。これは、Webファームシナリオで機能します。特定の理由がありましたら – IngAbraham

答えて

2

あなたはあなたのソリューションでそうはCtrl + F

セッション状態を使用します。コードからSessionの痕跡をすべて削除しないことをお勧めします。ユーザーの情報を保存する必要があり、この情報が重要な場合は、データベースに格納して後で照会するか、認証CookieのuserData部分を使用することができます。これは、セッションをどのように使用しているかによって異なります。

+0

? –

+2

@MuhammadAdeelZahid。セッションでは、拡張性のないステートフルなアプリケーションを書くことができます。セッションは既定では特定のWebサーバーのメモリに格納されているため、AppDomainがリサイクルされると(いつでも発生する可能性があります)、情報が失われます。多くのノードを持つWebファームで実行すると、特定のノードのメモリにSessionを格納すると、他のノードはそのノードにアクセスできなくなります。この場合、out-of-procセッションを使用する必要があります。あなたはセッションを使用すべきではない非常に多くの理由があります。 –

+0

@ DarinDimitrov-セッションを使用しない理由として私たちに可能性のある理由を教えてもらうために、時間がかかりますか?あなたはあなたの答えを更新することができます。ありがとうございました。 – Mubarek

0

セッションの代わりにクッキーを使用することは危険なアドバイスです。文字通りそれを取らないでください。クッキーはクライアントによって読み取られ、偽造され、サイズ制限があります。

次のことが可能です。

    共有サーバー上の
  1. 使用ASP.NETセッション状態サーバー。そうすれば、Webマシンはセッションを共有できます。
  2. スティッキセッションを使用する
  3. セッションのすべての用途を削除します。

これらの3つのソリューションをお勧めします。

関連する問題