143

এর বিরুদ্ধে আমার মাথাটি খুব বেশি দীর্ঘ ছড়িয়ে দিয়েছে। কোনও ব্যবহারকারীকে ফর্মস অ্যাটেন্টিকেশন.সাইনআউট ব্যবহার করে লগ আউট করার পরে কোনও সাইটের পৃষ্ঠাগুলি ব্রাউজ করা থেকে কীভাবে বাধা দেব? আমি এটি এটি করতে আশা করব:

FormsAuthentication.SignOut();
Session.Abandon();
FormsAuthentication.RedirectToLoginPage();

তবে তা হয় না। আমি যদি সরাসরি কোনও ইউআরএল টাইপ করি তবে আমি পৃষ্ঠাটিতে ব্রাউজ করতে পারি। আমি কিছুক্ষণের মধ্যে রোল-আপনার নিজস্ব সুরক্ষা ব্যবহার করি নি তাই আমি ভুলে যাই কেন এটি কার্যকর হয় না।

asp.net forms-authentication

— জেসন
সূত্র

সেই কোডটি ঠিক যেমন রয়েছে ... ব্রাউজারে ফিরে ক্লিক করা সার্ভারের পৃষ্ঠায় পুনরায় দেখা না করে এটি কেবল পৃষ্ঠার স্থানীয় ক্যাশেড সংস্করণটি পুনরায় লোড করে। নীচের সমস্ত সমাধান মনে হয় যে এই বিষয়টিকে উপেক্ষা করে এবং এখানে আপনি যা করছেন তার চেয়ে বেশি আসলে কিছুই করেন না। সংক্ষেপে ... এই প্রশ্নের কোনও উত্তর নেই যা ব্যবহারকারীর তাদের ক্যাশে দেখার বিষয়ে আজ অবধি সমাধান হবে আমি বিশ্বাস করি না ... জেএস বা সার্ভারের দিকনির্দেশনা সহ ক্যাশে সাফ করার কোনও উপায় আছে।

— যুদ্ধ

এই উত্তরটি যাচাইয়ের জন্য কিছু উপায় সরবরাহ করে, বিশেষত যদি আপনি সাইটটি PEN পরীক্ষায় ব্যর্থ হন: stackoverflow.com/questions/31565632/…

— টাইলার এস লয়েপার

211

ব্যবহারকারীরা এখনও আপনার ওয়েবসাইট ব্রাউজ করতে পারেন কারণ আপনি যখন কল করেন তখন কুকিজ সাফ হয় না FormsAuthentication.SignOut()এবং সেগুলি প্রতিটি নতুন অনুরোধে প্রমাণীকৃত হয়। এমএস ডকুমেন্টেশনে বলা হয়েছে যে কুকি সাফ হয়ে যাবে তবে তারা কি না? এর ঠিক একইরকম Session.Abandon(), কুকি এখনও আছে।

আপনার নিজের কোডটি এতে পরিবর্তন করা উচিত:

FormsAuthentication.SignOut();
Session.Abandon();

// clear authentication cookie
HttpCookie cookie1 = new HttpCookie(FormsAuthentication.FormsCookieName, "");
cookie1.Expires = DateTime.Now.AddYears(-1);
Response.Cookies.Add(cookie1);

// clear session cookie (not necessary for your current problem but i would recommend you do it anyway)
SessionStateSection sessionStateSection = (SessionStateSection)WebConfigurationManager.GetSection("system.web/sessionState");
HttpCookie cookie2 = new HttpCookie(sessionStateSection.CookieName, "");
cookie2.Expires = DateTime.Now.AddYears(-1);
Response.Cookies.Add(cookie2);

FormsAuthentication.RedirectToLoginPage();

HttpCookieহয় System.Webনামস্থান। এমএসডিএন রেফারেন্স ।

— ইগর জেরোসিমিć
সূত্র

18

এটি আমার পক্ষে কাজ করে। তবে এটি লক্ষণীয় যে লগ ইন করার সময় যদি ডোমেন সম্পত্তি ফর্মস অ্যাটেন্টিকেশন কুকিতে সেট করা থাকে তবে লগ আউট করার সময় কুকিটি সমাপ্ত করার সময় এটিও সেট করতে হবে

— ফিল হ্যালে

8

এছাড়াও কুকি 1

— দিমিত্রি জায়েট

6

এটি আমার কাছে আরও ভাল সমাধানের মতো বলে মনে হচ্ছে: রেসপন্স.কুকিজ [ফর্মসঅথেন্টিকেশন.ফোর্সসুকিইনাম] xp

— রেন্ডি এইচ

7

@RandyH। একটি নতুন খালি কুকির সাথে বিদ্যমান ফর্মস প্রমাণীকরণ কুকিকে ওভাররাইড করা নিশ্চিত করে যে ক্লায়েন্টটি যদি তাদের সিস্টেম ঘড়ির পিছনে ফিরে যায় তবে তারা এখনও কুকি থেকে কোনও ব্যবহারকারীর ডেটা উদ্ধার করতে সক্ষম হবে না।

— ত্রি কিউ ট্রান

9

এই মন্তব্যের উত্তরে কেউ কি একত্রিত করতে পারেন?

— ডেভিড

22

X64igor এবং ফিল হ্যাসেলডেন উপরের দুটি পোস্টিং ব্যবহার করে এটি সমাধান করেছেন:

1. x64igor লগআউটটি করার উদাহরণ দিয়েছিল:

আপনাকে প্রথমে লগআউটের প্রতিক্রিয়াতে খালি কুকিগুলি ফিরিয়ে প্রমাণীকরণ কুকি এবং সেশন কুকি সাফ করা দরকার ।

public ActionResult LogOff()
{
    FormsAuthentication.SignOut();
    Session.Clear();  // This may not be needed -- but can't hurt
    Session.Abandon();

    // Clear authentication cookie
    HttpCookie rFormsCookie = new HttpCookie( FormsAuthentication.FormsCookieName, "" );
    rFormsCookie.Expires = DateTime.Now.AddYears( -1 );
    Response.Cookies.Add( rFormsCookie );

    // Clear session cookie 
    HttpCookie rSessionCookie = new HttpCookie( "ASP.NET_SessionId", "" );
    rSessionCookie.Expires = DateTime.Now.AddYears( -1 );
    Response.Cookies.Add( rSessionCookie );

২. ফিল হ্যাসলডেন লগআউট করার পরে কীভাবে ক্যাচিং প্রতিরোধ করবেন তার উপরে উদাহরণ দিয়েছিলেন:

আপনাকে করার প্রয়োজন রেসপন্স মাধ্যমে ক্লায়েন্ট সাইড উপর ক্যাশে অপ্রমাণীকৃত ।

    // Invalidate the Cache on the Client Side
    Response.Cache.SetCacheability( HttpCacheability.NoCache );
    Response.Cache.SetNoStore();

    // Redirect to the Home Page (that should be intercepted and redirected to the Login Page first)
    return RedirectToAction( "Index", "Home" ); 
}

— justdan23
সূত্র

1

এই সমস্যাটি সমাধান করতে কাজে পুরো দিন নষ্ট করা। লগআউট বোতামে একবার কন্ট্রোলারে ভুল ক্রিয়াকলাপ কল করা শুরু হয় (লগইন নয় লগআউট)। আপনাকে ধন্যবাদ, এটি সমস্যার সমাধান করেছে। বিকাশের পরিবেশ: এএসপি.এনইট 4.51 এমভিসি 5.1

— আকো

1

ভাল উত্তর! নম্র পরামর্শ: ব্যবহার করুন ফর্ম ক্লিয়ারিং সেশন কুকি জন্য x64igor ব্যবহৃত:

SessionStateSection sessionStateSection = (SessionStateSection)WebConfigurationManager.GetSection("system.web/sessionState");             HttpCookie sessionCookie = new HttpCookie(sessionStateSection.CookieName, "");

। সাধারণভাবে, সেশন কুকির নামটি নয় "ASP.NET_SessionId"।

— বিস্কুট

20

আমার কাছে মনে হচ্ছে আপনার ওয়েবকনফিগ অনুমোদনের বিভাগটি সঠিকভাবে সেট আপ না করে। একটি উদাহরণ জন্য নিচে দেখুন।

<authentication mode="Forms">
  <forms name="MyCookie" loginUrl="Login.aspx" protection="All" timeout="90" slidingExpiration="true"></forms>
</authentication>
<authorization>
  <deny users="?" />
</authorization>

— jwalkerjr
সূত্র

এটি অনেক সহজ সমাধান, আমি এটিকে উত্তর হিসাবে চিহ্নিত করব। যেহেতু আমি কোডের একটি সংস্করণ বিভিন্ন সার্ভারে একটিতে কাজ করেছিলাম সে হিসাবে আমার এখানে অতিরিক্ত বৈশিষ্ট্যগুলি সেট করার দরকার নেই এবং আমি অন্যটি করেছি। সুতরাং কোড সংশোধন করা সঠিক সমাধান হওয়া উচিত নয়, কনফিগারেশন সংশোধন করা ভাল।

— ভ্লাদিমির বোজিক

ডিফল্টরূপে slidingExpiration TRUE (সেট করা হয় msdn.microsoft.com/library/1d3t3c61(v=vs.100).aspx )। এবং এর ফলে শেষ অবধি নির্ধারিত x মিনিটের পরে কুকিটি অবৈধ হয়ে উঠবে - এবং যখন সাইনআউট () এর মাধ্যমে ব্যবহারকারী লগ আউট হয় না not সুতরাং এর ফলে কোনও ব্যবহারকারীকে ফরমসৌথিক ব্যবহার ব্যবহার করে লগ করার কাঙ্ক্ষিত আচরণের ফলাফল হবে না। আমি ভুল হলে আমাকে সংশোধন করুন।

— ওলাফডাব্লু

12

এখানে মূল কথাটি হ'ল আপনি যদি "আমি সরাসরি কোনও URL টাইপ করি ..." say

ফর্ম প্রমাণীকরণের অধীনে ডিফল্টরূপে ব্রাউজার ব্যবহারকারীর জন্য পৃষ্ঠাগুলি ক্যাশে করে। সুতরাং, ব্রাউজারগুলির ঠিকানা বাক্সটি ড্রপডাউন থেকে সরাসরি কোনও URL নির্বাচন করা বা এটিতে টাইপ করে ব্রাউজারের ক্যাশে থেকে পৃষ্ঠাটি পেতে পারেন এবং প্রমাণীকরণ / অনুমোদন পরীক্ষা করতে সার্ভারে আর ফিরে যান না। এর সমাধান হ'ল প্রতিটি পৃষ্ঠার Page_Load ইভেন্টে বা আপনার বেস পৃষ্ঠার অন্লোড () এ ক্লায়েন্ট-সাইড ক্যাচিং প্রতিরোধ করা:

Response.Cache.SetCacheability(HttpCacheability.NoCache);

আপনি কল করতে পছন্দ করতে পারেন:

Response.Cache.SetNoStore();

— ফিল হাসেলডেন
সূত্র

11

আমি এর আগেও এর সাথে লড়াই করেছি।

যা চলছে বলে মনে হচ্ছে তার একটি সাদৃশ্য এখানে ... একটি নতুন দর্শনার্থী জো সাইটে আসে এবং ফর্মসৌথি ব্যবহার করে লগইন পৃষ্ঠার মাধ্যমে লগ ইন করে। এএসপি.নেট জোয়ের জন্য একটি নতুন পরিচয় তৈরি করে এবং তাকে একটি কুকি দেয়। সেই কুকিটি বাড়ির চাবিটির মতো এবং যতক্ষণ জো সেই চাবিটি নিয়ে ফিরে আসে ততক্ষণ সে লকটি খুলতে পারে। প্রতিটি দর্শকদের একটি নতুন কী এবং ব্যবহারের জন্য একটি নতুন লক দেওয়া হয়।

যখন FormsAuthentication.SignOut()ডাকা হয়, সিস্টেম জোকে চাবিটি হারাতে বলে। সাধারণত, এটি কাজ করে, যেহেতু জোয়ের আর চাবি নেই, তাই সে প্রবেশ করতে পারে না।

যাইহোক, জো যদি কখনও ফিরে আসে, এবং যদি তার হারিয়ে যাওয়া চাবি থাকে তবে তাকে ফিরে যেতে দেওয়া হবে!

আমি যা বলতে পারি, এএসপি ডট নেটকে দরজার তালা বদলানোর উপায় নেই!

আমি এটির সাথে যেভাবে বেঁচে থাকতে পারি তা হল সেশন ভেরিয়েবলের জোয়ের নামটি মনে রাখা। যখন সে লগ আউট করে, আমি অধিবেশনটি ত্যাগ করি যাতে আমার আর তার নাম না থাকে। পরে, তাকে অনুমতি দেওয়া হয়েছে কিনা তা যাচাই করার জন্য, আমি কেবল তার পরিচয়টির নামটি তুলনা করি current বর্তমান অধিবেশনটির নামটি এবং সেগুলির সাথে মেলে না, তবে তিনি বৈধ দর্শনার্থী নন।

সংক্ষেপে, কোনও ওয়েব সাইটের জন্য, User.Identity.IsAuthenticatedআপনার সেশন ভেরিয়েবলগুলি পরীক্ষা না করেও নির্ভর করবেন না !

— গ্লেন লিটল
সূত্র

8

+ 1, আমার মনে হয় এটিকে 'কুকি রিপ্লে আক্রমণ' বলা হয়। FormsAuthentication- এর সীমাবদ্ধতা সম্পর্কিত একটি নিবন্ধ রয়েছে S সাইনআউট: সমর্থন.

— দিমিত্রি

3

উপরের লিঙ্কটি অনুসরণ করতে চাইছেন এমন কারও জন্য এটি মারা গেছে। আপনি এই পৃষ্ঠার অনুলিপিটি পেতে এখানে ওয়েব্যাকম্যাচিন ব্যবহার করে চেষ্টা করতে পারেন, তবে এটি তাত্ক্ষণিকভাবে ব্যবহারকারীকে পুনর্নির্দেশ করার চেষ্টা করে। web.archive.org/web/20171128133421/https://…

— কিল্লা-বাইট

7

প্রচুর সন্ধানের পরে অবশেষে এটি আমার পক্ষে কাজ করেছিল। আমি আসা করি এটা সাহায্য করবে.

public ActionResult LogOff()
{
    AuthenticationManager.SignOut();
    HttpContext.User = new GenericPrincipal(new GenericIdentity(string.Empty), null);
    return RedirectToAction("Index", "Home");
}

<li class="page-scroll">@Html.ActionLink("Log off", "LogOff", "Account")</li>

— Khosro.Pakmanesh
সূত্র

আমি পিএইচপি তে বছরের পর বছর ধরে ওয়েব অ্যাপ্লিকেশন বিকাশ করছি। সুতরাং আমি এমভিসিতে নতুন ... আমি স্বীকার করি আমি এটি পছন্দ করি, তবে কে এত সহজ কিছু ভেবেছিল যে কাউকে লগ করা এত কঠিন হবে? আমি এই পৃষ্ঠার অন্যান্য স্ক্রিপ্টটি লাইনের নীচে চেষ্টা করেছি এবং এটি কেবলমাত্র কাজ করেছে। পোস্ট করার জন্য ধন্যবাদ!

— অ্যান্টনি গ্রিগস

6

এটি আমার পক্ষে কাজ করে

public virtual ActionResult LogOff()
    {
        FormsAuthentication.SignOut();
        foreach (var cookie in Request.Cookies.AllKeys)
        {
            Request.Cookies.Remove(cookie);
        }
        foreach (var cookie in Response.Cookies.AllKeys)
        {
            Response.Cookies.Remove(cookie);
        }
        return RedirectToAction(MVC.Home.Index());
    }

— Korayem
সূত্র

3

আপনার পোস্ট করা কোডটি দেখে মনে হচ্ছে এটির ফর্ম প্রমাণীকরণ টোকেনটি সঠিকভাবে সরিয়ে ফেলা উচিত, সুতরাং এটি সম্ভব যে প্রশ্নে থাকা ফোল্ডারগুলি / পৃষ্ঠাগুলি আসলে সুরক্ষিত নয়।

আপনি কি নিশ্চিত করেছেন যে লগইন হওয়ার আগে পৃষ্ঠাগুলি অ্যাক্সেস করা যাবে না?

আপনি যে ওয়েবকনফিগ সেটিংস এবং লগিন কোডটি ব্যবহার করছেন তা পোস্ট করতে পারেন?

— আব্রাম সাইমন
সূত্র

3

আমি আমার সমস্ত পৃষ্ঠাগুলির জন্য একটি বেস ক্লাস লিখছি এবং আমি একই ইস্যুতে এসেছি। আমার নীচের মত কোড ছিল এবং এটি কার্যকর হয়নি। ট্রেস করে, নিয়ন্ত্রণ পুনঃনির্দেশিত না করেই রেডিরেক্টটলগিনপেজ () স্টেটমেন্ট থেকে পরবর্তী লাইনে চলে যায়।

if (_requiresAuthentication)
{
    if (!User.Identity.IsAuthenticated)
        FormsAuthentication.RedirectToLoginPage();

    // check authorization for restricted pages only
    if (_isRestrictedPage) AuthorizePageAndButtons();
}

আমি খুঁজে পেয়েছি যে দুটি সমাধান আছে। হয় ফর্মআউটেন্টিফিকেশনকে পরিবর্তন করতে হবে ed হতে

if (!User.Identity.IsAuthenticated)
    Response.Redirect(FormsAuthentication.LoginUrl);

অথবা যোগ করে ওয়েবকনফিগ পরিবর্তন করতে

<authorization>
  <deny users="?" />
</authorization>

দ্বিতীয় ক্ষেত্রে, ট্রেস করার সময়, অনুরোধ করা পৃষ্ঠায় নিয়ন্ত্রণ পৌঁছায় না। ব্রেক পয়েন্টটি আঘাত করার আগে এটি অবিলম্বে লগইন ইউআরএলে পুনঃনির্দেশ করা হয়েছে। সুতরাং, সাইনআউট () পদ্ধতিটি সমস্যা নয়, পুনর্নির্দেশ পদ্ধতিটিই এক।

আমি আশা করি যে কেউ সাহায্য করতে পারে

শুভেচ্ছা সহ

— ওয়াহিদ শালালী
সূত্র

2

এছাড়াও আপনি Response.End (পেরেছিলাম) শুধু কলিং FormsAuthentication.RedirectToLoginPage () পরে

— murki

আমি মনে করি এমএসের পক্ষ থেকে কিছুটা ভুল ধারণা রয়েছে। আপনি যদি লোকেরা লগইন পৃষ্ঠায় ফিরে চান তবে আপনাকে লক আউট করতে হবে। অন্যথায় ফ্রেমওয়ার্কটি আনন্দের সাথে আপনাকে অ্যাক্সেসের অনুমতি দেবে। সুতরাং আপনি এই পোস্টে সমাধান বলতে হবে 2 2।

— জোশ রবিনসন

3

আমি এখানে কিছু পরামর্শ দেওয়ার চেষ্টা করেছি এবং আমি ব্রাউজারের পিছনে বোতামটি ব্যবহার করতে সক্ষম হয়ে যখন আমি একটি মেনু নির্বাচন ক্লিক করেছি তখন [অনুমোদন] টোকনটি যে [অ্যাকশনারসাল্ট] আমাকে সরাসরি লগইন স্ক্রিনে প্রেরণ করেছে।

আমার লগআউট কোডটি এখানে:

        FormsAuthentication.SignOut();
        Response.Cookies.Remove(FormsAuthentication.FormsCookieName);
        Response.Cache.SetExpires(DateTime.Now.AddSeconds(-1));
        HttpCookie cookie = HttpContext.Request.Cookies[FormsAuthentication.FormsCookieName];
        if (cookie != null)
        {
            cookie.Expires = DateTime.Now.AddDays(-1);
            Response.Cookies.Add(cookie);
        }

যদিও ব্রাউজারে পিছনের ফাংশনটি আমাকে ফিরিয়ে নিয়েছিল এবং সুরক্ষিত মেনুটি প্রদর্শন করে (আমি এখনও এটি নিয়ে কাজ করছি) আমি অ্যাপটিতে সুরক্ষিত কোনও কিছুই করতে সক্ষম হইনি।

আশাকরি এটা সাহায্য করবে

— DonH
সূত্র

ধন্যবাদ। এই সমাধানটি আমার পক্ষে কাজ করেছে ( <deny users="?" />ওয়েবকনফিগের প্রয়োজন নেই )

— আলেক্সি

3

আমি এই থ্রেডে বেশিরভাগ উত্তর চেষ্টা করেছি, কোনও ভাগ্য নেই। এটি দিয়ে শেষ:

protected void btnLogout_Click(object sender, EventArgs e)
{
    FormsAuthentication.Initialize();
    var fat = new FormsAuthenticationTicket(1, "", DateTime.Now, DateTime.Now.AddMinutes(-30), false, string.Empty, FormsAuthentication.FormsCookiePath);
    Response.Cookies.Add(new HttpCookie(FormsAuthentication.FormsCookieName, FormsAuthentication.Encrypt(fat)));
    FormsAuthentication.RedirectToLoginPage();
}

এটি এখানে পেয়েছে : http://forums.asp.net/t/1306526.aspx/1

— stoffen
সূত্র

3

এই উত্তরটি প্রযুক্তিগতভাবে খসরো.পকমনেশের মতো। আমি তার উত্তর কীভাবে এই থ্রেডের অন্যান্য উত্তরগুলির থেকে পৃথক, এবং কোন ক্ষেত্রে এটি ব্যবহার করা যেতে পারে তা স্পষ্ট করতে পোস্ট করছি।

সাধারণভাবে একটি ব্যবহারকারী-সেশন সাফ করার জন্য, করছেন

HttpContext.Session.Abandon();
FormsAuthentication.SignOut();

কার্যকরভাবে ব্যবহারকারীকে লগ আউট করবে। তবে , যদি একই অনুরোধে আপনার পরীক্ষা করা দরকার Request.isAuthenticated(উদাহরণস্বরূপ কোনও অনুমোদন ফিল্টারে প্রায়শই ঘটতে পারে), তবে আপনি এটি দেখতে পাবেন

Request.isAuthenticated == true

এমনকি _ পরে আপনি HttpContext.Session.Abandon()এবং FormsAuthentication.SignOut()।

কাজটিই করছিল একমাত্র কাজ

AuthenticationManager.SignOut();
HttpContext.User = new GenericPrincipal(new GenericIdentity(string.Empty), null);

যে কার্যকরভাবে সেট Request.isAuthenticated = false।

— seebiscuit
সূত্র

2

আমি যখন প্রমাণীকরণ> ফর্মগুলি> পথের সম্পত্তিটি সেট করি তখন এটি আমার কাছে ঘটতে শুরু করে Web.config। এটি মুছে ফেলার ফলে সমস্যাটি স্থির হয়ে যায় এবং একটি সাধারণ FormsAuthentication.SignOut();আবার কুকি সরিয়ে দেয়।

— বিপিএম
সূত্র

1

এটি এমন হতে পারে যে আপনি একটি সাবডোমেন (sub1.domain.com) থেকে লগ ইন করছেন এবং তারপরে একটি পৃথক সাবডোমাইন (www.domain.com) থেকে লগআউট করার চেষ্টা করছেন।

— jorsh1
সূত্র

1

আমার ঠিক একই সমস্যা ছিল, যেখানে সাইনআউট () আপাতদৃষ্টিতে টিকিটটি সরাতে ব্যর্থ হয়েছিল। তবে কেবলমাত্র একটি নির্দিষ্ট ক্ষেত্রে যেখানে অন্য কিছু যুক্তি একটি পুনর্নির্দেশের কারণ ঘটেছে। আমি এই দ্বিতীয়টি পুনঃনির্দেশ সরিয়ে দেওয়ার পরে (এটিকে একটি ত্রুটি বার্তার সাহায্যে প্রতিস্থাপন করেছি) সমস্যাটি চলে গেল।

সমস্যাটি অবশ্যই ছিল যে পৃষ্ঠাটি ভুল সময়ে পুনঃনির্দেশিত হয়েছিল, অতএব প্রমাণীকরণকে ট্রিগার করে না।

— পেডার স্কু
সূত্র

1

আমার এখন একই ধরণের সমস্যা হচ্ছে এবং আমি বিশ্বাস করি যে আমার ক্ষেত্রে সমস্যাটি আসল পোস্টারের পাশাপাশি পুনঃনির্দেশের কারণে। ডিফল্টরূপে একটি প্রতিক্রিয়া edসত্যচারণ একটি ব্যতিক্রম ঘটায় যা তা ধরা না দেওয়া অবধি ততক্ষণ বুদবুদ হয়ে যায় এবং পুনরায় পুনর্নির্দেশ অবিলম্বে সম্পাদন করা হয় না, আমি অনুমান করছি যে এটি পরিবর্তিত কুকি সংগ্রহটি ক্লায়েন্টের নিকট থেকে নিরস্ত করা থেকে বিরত করছে। আপনি যদি নিজের কোডটি ব্যবহারের জন্য পরিবর্তন করেন তবে:

Response.Redirect("url", false);

এটি ব্যতিক্রম প্রতিরোধ করে এবং মনে হয় কুকিকে ক্লায়েন্টকে সঠিকভাবে ফেরত পাঠানো দেওয়া হবে।

— lostatredrock
সূত্র

1

আপনি যখন লগ ইন চাপুন তখন একটি সেশন ভেরিয়েবল প্রেরণ করার চেষ্টা করুন, এবং স্বাগতম পৃষ্ঠায়, প্রথমে সেশনটি পৃষ্ঠাটির লোডে বা ইনিশ ইভেন্টে খালি কিনা তা পরীক্ষা করুন:

if(Session["UserID"] == null || Session["UserID"] == "")
{
    Response.Redirect("Login.aspx");
}

— Devrishi
সূত্র

1

আমার জন্য, নিম্নলিখিত পদ্ধতির কাজ করে। আমি মনে করি "ফর্মস অ্যাটেন্টিকেশন.সাইনআউট ()" বিবৃতি দেওয়ার পরে যদি কোনও ত্রুটি থাকে তবে সিঙ্গআউট কাজ করে না।

public ActionResult SignOut()
    {
        if (Request.IsAuthenticated)
        {
            FormsAuthentication.SignOut();

            return Redirect("~/");
        }
        return View();
     }

— Aji স্বাগতম
সূত্র

0

আপনি কি আইই ব্যবহার করে এই আচরণটি পরীক্ষা করছেন / দেখছেন? এটা সম্ভব যে IE এই পৃষ্ঠাগুলি ক্যাশে থেকে পরিবেশন করছে। এটির ক্যাশে ফ্লাশ করা আইআইকে পাওয়া কুখ্যাত এবং তাই অনেক সময় লগ আউট করার পরেও "সুরক্ষিত" পৃষ্ঠাগুলির একটির ইউআরএল টাইপ করা ক্যাশে থাকা সামগ্রীটি আগে থেকেই প্রদর্শন করে।

(আপনি অন্য ব্যবহারকারী হিসাবে লগ ইন করার পরেও আমি এই আচরণটি দেখেছি এবং IE পুরানো ব্যবহারকারীর ব্যবহারকারীর নাম সহ আপনার পৃষ্ঠার শীর্ষে "স্বাগতম" বারটি দেখায় adays আজকাল সাধারণত সাধারণত একটি পুনরায় লোড এটি আপডেট করে তবে যদি এটি স্থির থাকে তবে , এটি এখনও ক্যাচিংয়ের সমস্যা হতে পারে))

— Stobor
সূত্র

0

সেশন.বান্ডন () করা এবং কুকি ধ্বংস করা বেশ ভাল কাজ করে। আমি এমভিসি 3 ব্যবহার করছি এবং দেখে মনে হচ্ছে সমস্যাটি ঘটে যদি আপনি কোনও সুরক্ষিত পৃষ্ঠায় যান, লগ আউট করেন এবং আপনার ব্রাউজারের ইতিহাসে যান। কোনও বড় বিষয় নয় তবে এখনও বিরক্তিকর এক ধরনের ঘটনা।

আমার ওয়েব অ্যাপ্লিকেশনটিতে লিঙ্কগুলি দিয়ে যাওয়ার চেষ্টা যদিও সঠিকভাবে কাজ করে।

এটি ব্রাউজারের ক্যাশে না করা সেট করার উপায় হতে পারে।

— জেমস
সূত্র

0

এমভিসির পক্ষে এটি আমার পক্ষে কাজ করে:

        public ActionResult LogOff()
        {
            FormsAuthentication.SignOut();
            return Redirect(FormsAuthentication.GetRedirectUrl(User.Identity.Name, true));
        }

— anovo
সূত্র

0

সমস্যাটি বোঝার জন্য আমি কিছু তথ্য যুক্ত করতে চেয়েছিলাম। ফর্ম প্রমাণীকরণ ব্যবহারকারীর ডেটা কোনও কুকিতে বা URL এর কোয়েরি স্ট্রিংয়ে সংরক্ষণ করার অনুমতি দেয়। আপনার সাইটটি যে পদ্ধতিটিকে সমর্থন করে তা ওয়েবকনফাইগ ফাইলে কনফিগার করা যায়।

মাইক্রোসফ্ট অনুসারে :

সাইনআউট পদ্ধতিটি কুকি বা ইউআরএল থেকে ফর্ম-প্রমাণীকরণের টিকিটের তথ্য সরিয়ে দেয় যদি কুকিজ সমর্থনযোগ্য মিথ্যা থাকে ।

একই সাথে, তারা বলে :

HTTPCookieMode মানগুলির মধ্যে একটি যা ইঙ্গিত দেয় যে অ্যাপ্লিকেশনটি কুকিবিহীন ফর্ম প্রমাণীকরণের জন্য কনফিগার করা আছে কিনা। ডিফল্ট UseDeviceProfile হয় ।

সবশেষে, ইউজডেভাইসপ্রাইফাইল সম্পর্কিত, তারা বলে :

যদি কুকিমোড সম্পত্তি ব্যবহারের ডেভিসপ্রাইফেলিতে সেট করা থাকে তবে বর্তমান অনুরোধের ব্রাউজার যদি কুকি উভয় সমর্থন করে এবং কুকিজের সাথে পুনঃনির্দেশিত করে তবে কুকিজ সমর্থনযোগ্য সম্পত্তি সত্য হবে ; অন্যথায়, কুকিজ সমর্থিত সম্পত্তি মিথ্যা ফিরিয়ে দেবে।

এই সমস্ত একত্রে পাইকিং করা, ব্যবহারকারীর ব্রাউজারের উপর নির্ভর করে ডিফল্ট কনফিগারেশনের ফলে কুকিজ সমর্থন করা সত্য হতে পারে , যার অর্থ সাইনআউট পদ্ধতিটি কুকি থেকে টিকিট সাফ করে না। এটি পাল্টা স্বজ্ঞাত বলে মনে হচ্ছে এবং কেন এটি এইভাবে কাজ করে তা আমি জানি না - আমি প্রত্যাশা করব সাইনআউট প্রকৃতপক্ষে কোনও পরিস্থিতিতে ব্যবহারকারীকে সাইন আউট করবে।

সাইনআউটকে নিজেই কাজ করার একটি উপায় হ'ল ওয়েলকনফিগ ফাইলে কুকি মোডটি "ইউজকুকিজ" (অর্থাত কুকিগুলির প্রয়োজন) তে পরিবর্তন করা:

<authentication mode="Forms">
  <forms loginUrl="~/Account/SignIn" cookieless="UseCookies"/>
</authentication>

আমার পরীক্ষাগুলি অনুসারে, এটি করা আপনার সাইটের ব্যয়ে সাইনআউট নিজেই কাজ করে তোলে এখন কুকিজকে সঠিকভাবে কাজ করতে হবে।

— RogerMKE
সূত্র

আমি মনে করি আপনি এটি ভুল পড়ছেন। সাইনআউট () সম্পর্কিত, আমি দৃ sure়ভাবে নিশ্চিত যে এগুলির অর্থ হ'ল কুকিজসপোর্টার্ড মিথ্যা থাকলে অন্যথায় কুকি থেকে এটি URL থেকে সাফ হয়ে যাবে from অর্থাৎ তাদের লেখা উচিত ছিল "সাইনআউট পদ্ধতিটি কুকি থেকে ফর্ম-প্রমাণীকরণের টিকিটের তথ্য সরিয়ে দেয় বা যদি কুকিজসপোর্টটি মিথ্যা থাকে তবে URL থেকে।"

— ওসকার বার্গগ্রেন

-1

জেনে রাখুন যে স্টোন হতে রাজি যদি এসটিএস থেকে wsignoutcleanup বার্তা আইআইএস থেকে অ্যাপ্লিকেশনের নাম url সহ মিলছে না কুকিজ পরিষ্করণ ব্রাউজার বলতে, এবং আমি গড় কেস সংবেদনশীল । ডাব্লুআইএফ সবুজ ওকে চেক দিয়ে সাড়া দেয়, তবে তা করবে না ব্রাউজারে কুকিজ মুছতে কমান্ডটি প্রেরণ ।

সুতরাং, আপনার url এর ক্ষেত্রে সংবেদনশীলতার দিকে আপনাকে মনোযোগ দিতে হবে।

উদাহরণস্বরূপ, থিঙ্কটেকচার আইডেন্টিটি সার্ভার ভিজিটিং আরপিগুলির ইউআরএলগুলি একটি কুকিতে সংরক্ষণ করে, তবে এটি তাদের সকলকে নিম্নতর করে তোলে। ডাব্লুআইএফ নিম্ন ক্ষেত্রে wsignoutcleanup বার্তাটি গ্রহণ করবে এবং এটি আইআইএসের অ্যাপ্লিকেশন নামের সাথে তুলনা করবে। যদি এটি মেলে না, এটি কোনও কুকিজ মুছবে না, তবে ব্রাউজারে ঠিক আছে report সুতরাং, এই পরিচয় সার্ভারের জন্য আমাকে এই জাতীয় সমস্যাগুলি এড়ানোর জন্য ওয়েবকনফাইগের সমস্ত ইউআরএল এবং আইআইএস-এ সমস্ত অ্যাপ্লিকেশন নাম লিখতে হবে such

এছাড়াও আপনার যদি এসটিএসের সাবডোমেনের বাইরে অ্যাপ্লিকেশন থাকে তবে ব্রাউজারে তৃতীয় পক্ষের কুকিজকে মঞ্জুরি দিতে ভুলবেন না, অন্যথায় ব্রাউজারের কুকিজ মুছে ফেলা হবে না যদিও ডাব্লুআইএইফ তাকে বলে।

— স্টিফান
সূত্র

1

স্টোন? এসটিএস? থিঙ্কটেকচার আইডেন্টিটি সার্ভার? এই সমস্ত জিনিস কি এবং তারা এই প্রশ্নের সাথে কীভাবে সম্পর্কিত?

— ওসকার বার্গগ্রেন

FormsAuthentication.SignOut () ব্যবহারকারীকে লগ আউট করে না