Access session in CustomReportResolver?

9 posts, 1 answers
  1. Dan
    Dan avatar
    202 posts
    Member since:
    May 2006

    Posted 01 Jul 2014 Link to this post

    I have an InstanceReportSource report to use in my MVC application, so I am using the IReportResolver and CustomReportResolver to set up the report for my reportviewer.  In order to set up the report I need access to Session for an authentication object.  However, Session is not available in the CustomReportResolver method.

    Is there anyway to get to Session from there, or can it be modified to do so?

    Thanks.
    Dan
  2. Answer
    Stef
    Admin
    Stef avatar
    3610 posts

    Posted 03 Jul 2014 Link to this post

    Hi Dan,

    Using session variables in an MVC project is not recommended.

    If you still want to work with the ASP.NET Session, searching the web points to settings that can allow you to access it in Web API controllers:



    Regards,
    Stef
    Telerik
     

    Check out the Telerik Platform - the only platform that combines a rich set of UI tools with powerful cloud services to develop web, hybrid and native mobile apps.

     
  3. Dan
    Dan avatar
    202 posts
    Member since:
    May 2006

    Posted 08 Jul 2014 Link to this post

    Thanks.  I used the second link that you posted, and it seems to be working.  The session variables are required in my app.

    Thanks.  Dan
  4. Mike
    Mike avatar
    11 posts
    Member since:
    Feb 2015

    Posted 02 Nov 2018 Link to this post

    Hello,  I tried the solution mentioned below(The 2nd option).  It works except in one situation.  I believe it has something to do with the fact I have sub reports on my screen. I am able to get my session within the Resolve function of my custom resolver but it runs through that function 3 times.  On the 3rd time HttpContext.Current is null.  I have to be able to get the session here because I have to validate some values from it.  I am not sure why it would be null on the last call. I did step through the Application_PostAuthorizeRequest function and it does call SetSessionStateBehavior just like it did the first 2 times before the Resolve function was called.  I cannot think of another way to inject this because the IReportResolver stores the configuration(and resolver) in a static property and therefore my only option without session overwriting is to get this from within the Resolve function.  Obviously, I could continue using the code we had before we upgraded to 12.2.18.1017.  However, we were setting the report source without using a resolver which we would have passed to the new MVC wrapper for ReportViewer's ReportSource function.  My build says that function is obsolete so we were trying to implement the new UriReportSource and use a resolver but ran into the issue I mentioned.  Any idea how to get the session on the last pass?  I tried storing the report source from the previous pass but realized this would not work because again the resolver is within a static context and therefore if multiple users are using the application there could be an overwrite of that property.
  5. Mike
    Mike avatar
    11 posts
    Member since:
    Feb 2015

    Posted 05 Nov 2018 in reply to Mike Link to this post

    Here is the API that is made just before the 3rd Resolve call.

    "/api/reports/clients/02b97711ca4/instances/38dfedd32eb/documents/94eb4a5f91400c4290b7eb/info"

  6. Mike
    Mike avatar
    11 posts
    Member since:
    Feb 2015

    Posted 05 Nov 2018 in reply to Mike Link to this post

    Think I found a way.  The main reason I was trying to gain access to the session was to set the connection string dynamically by using the session to figure out where I should be connected from within the Resolve function.  In the following link I realized I can do this via a report parameter.  I am going to try that.  So that from my MVC side of code can provide the connection string since it should already be within the context of my session and I don't have to rely on Web API through Telerik to provide my access to it.

     

    https://docs.telerik.com/reporting/knowledge-base/how-to-pass-connectionstring-to-report-dynamically-through-report-parameter

  7. Todor
    Admin
    Todor avatar
    279 posts

    Posted 07 Nov 2018 Link to this post

    Hello Mike,

    Setting the connection string dynamically through a report parameter is the approach we recommend.

    For the HttpContext-related issues you can check How to use information from HttpContext in Custom Report Resolver KB article, where we have explained the reason for HttpContext *not* to be available in report rendering thread, and the workaround to use the information from it if necessary.

    Regards,
    Todor
    Progress Telerik
    Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Feedback Portal and vote to affect the priority of the items
  8. Mike
    Mike avatar
    11 posts
    Member since:
    Feb 2015

    Posted 14 Dec 2018 in reply to Todor Link to this post

    Thanks again Todor.  Using the UserIdentity code worked for me. As a side note.  Getting the session information any other way will cause you security issues when your "identity" is stored within a session. For example, with my old code before your fix.  I would get the session information correctly.  However, if I logged into another user account in my application.  The previous session values were used and I saw data in the report that I should not have seen.  I am sure this is because the report resolver is expected to be a static reference. 
  9. Todor
    Admin
    Todor avatar
    279 posts

    Posted 19 Dec 2018 Link to this post

    Hi Mike,

    Indeed, if the resolver is created in the static constructor of the ReportsController class (our default implementation), it will be reused with all clients until the application gets restarted and some report information from one session may be accessible by another.
    Note that the report resolver may be created also in the normal constructor to avoid this - at the cost of the corresponding additional resources.

    I agree that the newly introduced UserIdentity is a better approach for passing current user data to the report. It may be considered as further improvement along with the performance enhancement related to report rendering engine of all REST reports services using dedicated rendering thread queue (the feature that required UserIdentity to be introduced).

    Regards,
    Todor
    Progress Telerik
    Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Feedback Portal and vote to affect the priority of the items
Back to Top