locked
Session cleared on Postback RRS feed

  • Question

  • User1981308836 posted

    I have an application built on MVC C#, that has been running for around like 6 years, and recently there is a problem with "Sessions", ie., when the user does a transaction, if 3ds is required, they would be taken to the 3ds page, and we would normally receive a postback with the status, and Sessions were used to hold the temporary data on this, and now these Sessions are being cleared on postback and its null.

    We tested this on the local development machine, and even tried using a new bare MVC C# Web Application, created straight out of the template, and there too, the Sessions were being cleared, and strange enough, only when being receiving a postback from the 3ds page, the other postbacks works as expected.

    Additionally, the sessions were being active (on the bare Web app) when we tried opening them on a new window, and when being postbacked it gets cleared, only on the page when the 3ds lands, on the rest of the pages it works.

    We use MVC 5.2.7 with C# .Net Framework 4.8

    We tried looking up on the various session related issues posted on SO and tried out the solutions marked, but none worked.

    Sunday, April 19, 2020 7:14 AM

All replies

  • User475983607 posted

    If you want community support then the community needs your sample code that reproduces this issue.  

    only when being receiving a postback from the 3ds page, the other postbacks works as expected.

    I'm not sure what a 3ds page is but I'm assuming it's a 3rd party application.   The user's session is has never been available in this scenario.   The post is coming from the 3rd party application not the user's browser. 

    Sunday, April 19, 2020 11:47 AM
  • User1981308836 posted

    Yes 3ds is 3rd party, and yes, the post is coming from the 3rd party application.

    The problem is. this used to work earlier,

    The Flow would be
    My App [Step 1] -redirects to-> 3ds page (3rd party) [Step 2] -redirects to-> My App [Step 3]

    And the session which is set initially on [Step 1] is being cleared after its being redirected from 3ds page on [Step 3], so technically, the session should have been available on [Step 3] but its not.

    Sunday, April 19, 2020 11:58 AM
  • User475983607 posted

    Yes 3ds is 3rd party, and yes, the post is coming from the 3rd party application.

    The problem is. this used to work earlier,

    The Flow would be
    My App [Step 1] -redirects to-> 3ds page (3rd party) [Step 2] -redirects to-> My App [Step 3]

    And the session which is set initially on [Step 1] is being cleared after its being redirected from 3ds page on [Step 3], so technically, the session should have been available on [Step 3] but its not.

    You are mistaken.   Session does not work that way.  Session is state persisted between the user's browser and the application.  The user's Session is not available when the 3rd party posts to the web application but it is, or should be, available when the user's browser makes the next HTTP request.

    Sunday, April 19, 2020 12:11 PM
  • User1981308836 posted

    You are mistaken.   Session does not work that way.  Session is state persisted between the user's browser and the application.  The user's Session is not available when the 3rd party posts to the web application but it is, or should be, available when the user's browser makes the next HTTP request.

    Thanks for the explanation and quick responses.

    and thinking of the same, prior to posting the question, I created a dummy application that receives the request from "My App" and does a postback with dummy data back again to "My App", and the session was held in that case.

    Session is state persisted between the user's browser and the application

    Here, the session is persisted between the application and the user browser using the "Asp.Net Session cookie" as per my understanding, and we even checked this value if this is being changed, and it didn't. So shouldn't the session which is associated to that cookie be present as well? and I tried opening a new tab right next to this to confirm, and the session was active there, but null on the page which was redirected back from 3ds.

    And as mentioned earlier, the session used to work, ie., it was available after being postback'd from the 3ds page earlier (like before 3 months), and thinking that the recent changes to the code might have caused this, we even tried creating a new application out of the default template, and had the 3ds page postback to that new application, and there too the session became null.

    Sunday, April 19, 2020 12:25 PM
  • User475983607 posted

    Here, the session is persisted between the application and the user browser using the "Asp.Net Session cookie" as per my understanding, and we even checked this value if this is being changed, and it didn't. So shouldn't the session which is associated to that cookie be present as well? and I tried opening a new tab right next to this to confirm, and the session was active there, but null on the page which was redirected back from 3ds.

    If the 3rd party is redirecting the user's browser back to your site then Session should be maintained.  If it's not then it could be Session was set on a secured page HTTPS but the redirect goes to HTTP.  This can also happen if you redirect to a sub domain.  Compare the URL from the redirected tab to the "new tab".

    Sunday, April 19, 2020 12:52 PM
  • User1981308836 posted

    If the 3rd party is redirecting the user's browser back to your site then Session should be maintained.  If it's not then it could be Session was set on a secured page HTTPS but the redirect goes to HTTP.  This can also happen if you redirect to a sub domain.  Compare the URL from the redirected tab to the "new tab".

    Both are on HTTPS, and there are no subdomains

    Compare the URL from the redirected tab to the "new tab".


    Its exactly the same, we copied and pasted it to be sure. We made the action where 3ds lands accepts both [GET] and [POST] for testing this scenario.

    Sunday, April 19, 2020 1:00 PM
  • User475983607 posted

    If I understood your original post, you were able to recreate this issue using a demo.   Can you share this code?

    Sunday, April 19, 2020 1:11 PM
  • User1981308836 posted
    public ActionResult Index()
    {
        // The session for "random" is set, this is the default landing page of the 
        // application
        Session["random"] = "2";
        return View();
                
    }
    
    public ActionResult About()
    {
        // This ViewBag Message will be disaplayed on the About View Page
        ViewBag.Message = Session["random"]?.ToString()??"hmm";            
        return View();
    }
    
    // This is the landing page for 3ds on the demo app
    [HttpPost]
    public ActionResult About(string id)
    {
        // This ViewBag Message will be disaplayed on the About View Page
    
        ViewBag.Message = Session["random"]?.ToString() ?? "hmm";
        return View();
    }

    and this was the result, to the left, is the one which was postbacked from the 3ds page, the right is [GET] which was opened after we received the postback from 3ds.

    Sunday, April 19, 2020 1:21 PM
  • User475983607 posted

    I cannot reproduce this issue.   I used your code and  when I set a Session value it persists as expected regardless of where the browser is directed or redirected.

    Keep in mind, the only way the 3rd party application can post to your application is if it generates a self-posting form.  Usually, a 3rd party application redirects; HTTP GET.  Is the 3rd party application returning an self-posting HTML form?   

    Maybe try debugging using the browser's dev tools so you can see what's happening.  

    Sunday, April 19, 2020 1:57 PM
  • User1981308836 posted

    Is the 3rd party application returning an self-posting HTML form?   

    yes,

    Maybe try debugging using the browser's dev tools so you can see what's happening.  

    Tried, there are no visible changes to the cookies used by our application when its being redirected from the 3ds page

    Sunday, April 19, 2020 2:05 PM
  • User475983607 posted

    I cannot reproduce this issue no matter how I try.  You'll need to troubleshoot. 

    Cookies are deterministic.   Either the browser sends the cookie or it doesn't.  If the cookie makes its way to the web application and the framework cannot load the user's session then somehow the use's session was cleared.   That can happen if the application restarts.  Also, keep in mind, cookies are browser specific not tab.  If your test has another tab open and Session is still working on that tab then there must be a bug.

    Sunday, April 19, 2020 2:40 PM
  • User1981308836 posted

    I cannot reproduce this issue no matter how I try.  You'll need to troubleshoot. 

    Can you share me any options for this, have already tried everything I can think of, built a test app to check if this was due to the code on the original app,
    Checked through the sessions and cookie data on browsers, tried checking the cookies which are sent on the request from the 3ds page, added breakpoints points on all the sections which can cause a session clear / abandon and tried checking if the application restarts.

    I cannot reproduce this issue no matter how I try.  You'll need to troubleshoot. 

    As mentioned this only happens when its redirected from 3ds, and normally with any other web applications, it works fine

    Cookies are deterministic.   Either the browser sends the cookie or it doesn't.  If the cookie makes its way to the web application and the framework cannot load the user's session then somehow the use's session was cleared.   That can happen if the application restarts.

    The application was in debug mode, with debug points set on its lifecycle events, but it was not restarted or crashed which might cause a restart.

    Also, keep in mind, cookies are browser specific not tab.  If your test has another tab open and Session is still working on that tab then there must be a bug.

    I understand that the cookies are browser specific, which is why i opened a new tab/window instead of opening it on another browser and have tried it on different browsers as well, but with no avail, the session clears on all browsers. so this bug cannot be browser specific right? and from the application end, and if on the test app, then I am unsure where, as that was right off the template :( 


    Sunday, April 19, 2020 2:53 PM
  • User665608656 posted

    Hi, surya_8

    If you did not execute "Index" before entering the “About” page, then your "Session ["random"]" value is empty, which is why your page is displayed as "hmm".

    If you enter the “Index” page and then the “About” page, you will find that "Session [" random "]" is set as ”2”.

    Therefore, I guess your session is not cleared after the post, but before the post did not enter the method of setting up the session.

    So, I suggest that you check the sequence of your execution by breaking points.

    Best Regards,

    YongQing.

    Monday, April 20, 2020 9:43 AM
  • User1981308836 posted

    Hi, surya_8

    If you did not execute "Index" before entering the “About” page, then your "Session ["random"]" value is empty, which is why your page is displayed as "hmm".

    If you enter the “Index” page and then the “About” page, you will find that "Session [" random "]" is set as ”2”.

    Therefore, I guess your session is not cleared after the post, but before the post did not enter the method of setting up the session.

    So, I suggest that you check the sequence of your execution by breaking points.

    Best Regards,

    YongQing.



    This is code for the test application, and it was validated only after the executing the "index" page, and if you have noticed the screenshot I shared earlier,

    the window to the left, is the one to which 3DS has postbacked to, whereas the one on the right was opened after we received the postback, and from this you can see that session has been set, (ie.,) the index page was loaded at first to set the session, else it would have been rendered "hmm" as well.

    Monday, April 20, 2020 9:50 AM
  • User753101303 posted

    Hi,

    You updated your browser maybe? Could it be caused by https://www.chromium.org/updates/same-site

    Monday, April 20, 2020 10:15 AM
  • User1981308836 posted

    We tried with IE & Firefox, both resulted in the same error, and we are using secure cookies, so Rejection of cookies on Chrome would not be likely.

    Monday, April 20, 2020 10:52 AM
  • User475983607 posted

    surya_8

    We tried with IE & Firefox, both resulted in the same error, and we are using secure cookies, so Rejection of cookies on Chrome would not be likely.

    The community can only guess without source code that reproduces this issue.  So far you've stated the 3DS site is redirects, posts back, and a returns a self-submitting form.  Which is it?  What is the actual redirect URL configured in the 3DS site?  Can you share your Session and cookie configuration?   Is the 3DS site a payment gateway?  OAuth Server? 

    Monday, April 20, 2020 11:30 AM
  • User753101303 posted

    Ok and you told the flow is :

    redirects to-> 3ds page (3rd party) [Step 2] -redirects to-> My App [Step 3]

    The POST request is done directly by the 3rd party server to your app during step 2?  I would expect the current described behavior unless maybe cookieless session is enabled (the session is part of the url and so if you give this url to the 3rd party server it might work).

    My preference would be likely to not wondering why it worked before and changed my design so that the 3rd party POST doesn't depend on the session. It depends on the 3rd party but AFAIK it commonly allows to pass an id that you'll get back with POSTed data and that could allow to retrieve whatever you need.

    Edit: for debugging POSTs doen from a 3rd party server, you could try https://docs.microsoft.com/en-us/dotnet/api/system.web.httprequest.saveas?view=netframework-4.8 to save the full http request to a file and inspect its content.

    Monday, April 20, 2020 11:59 AM
  • User1981308836 posted

    The community can only guess without source code that reproduces this issue.  So far you've stated the 3DS site is redirects, posts back, and a returns a self-submitting form.  Which is it?  What is the actual redirect URL configured in the 3DS site?  Can you share your Session and cookie configuration?   Is the 3DS site a payment gateway?  OAuth Server? 

    3DS uses self-submitting form to postback the data back to our application, so the user would be redirected from the 3ds to our application.
    The redirect URL is dynamic, and it can be set when we the application redirects to the 3ds url which is obtained through an API call with the payment gateway.
    3DS site is payment gateway's

    Can you share your Session and cookie configuration?

    <httpCookies requireSSL="true" /> 
    <sessionState timeout="2000" />
    Monday, April 20, 2020 12:27 PM
  • User1981308836 posted


    Edit: for debugging POSTs doen from a 3rd party server, you could try https://docs.microsoft.com/en-us/dotnet/api/system.web.httprequest.saveas?view=netframework-4.8 to save the full http request to a file and inspect its content.

    Thanks, will try this out.

    The POST request is done directly by the 3rd party server to your app during step 2?  I would expect the current described behavior unless maybe cookieless session is enabled (the session is part of the url and so if you give this url to the 3rd party server it might work).

    Yes, its done directly by the 3DS to our application on Step 2.

    My preference would be likely to not wondering why it worked before and changed my design so that the 3rd party POST doesn't depend on the session. It depends on the 3rd party but AFAIK it commonly allows to pass an id that you'll get back with POSTed data and that could allow to retrieve whatever you need.

    This is what we did currently, but if the root cause for why it fails can be identified, then it would be useful to prevent any issues like this further and to answer our stake holders.

    Monday, April 20, 2020 12:32 PM
  • User753101303 posted

    By default the session id is stored in a cookie (or you used cookieless session previously and changed that?) so if it worked it means that:
    - the session id cookie needs to be sent to the 3rd party server
    - and needs to be forwarded by the 3rd party server when doing the POST request directly without going through the browser

    For #2 there is absolutely nothing you can do and so you depend on what they have done. Maybe they changed that breaking your previous design?

    Unless the 3rd party is telling explicitely they do support that I would avoid to base my design on an unspecified behavior on which I have no control.

    Monday, April 20, 2020 1:36 PM
  • User665608656 posted

    Hi, surya_8 

    Your application will add a cookie (key: JSESSIONID, value: XXX) to the browser's cookie. After you enter a 3rd party application, for example, you have performed a payment operation, the value of the session in the cookie is also JSESSIONID, so the value of the session in the cookie is modified on Postback. When you return to your application, I guess your application will have user authentication, and the original JSESSIONID will not be found at this time.

    I suggest that you store your JSESSIONID before entering the third-party, and take it out after you have successfully paid. As far as I know, the general three-party interface will have public parameters (or private domains) to store other information of the user. After the interface call is completed, it will be returned as is. You can store the JSESSIONID in this.

    Best Regards,

    YongQing.

    Wednesday, April 22, 2020 5:15 AM