I'm looking to get some input on the best way to achieve handling different sessions with multiple Salesforce tabs (classic but eventually moving to lightning) with server side Blazor.
I was tasked with creating an application to be framed within a Visual Force page within Salesforce (wasn't a fan of creating a secure iframe architecture but that's besides the point). The application was created as an ASP.NET Framework MVC web application and uses session state for state management upon a successful SSO request.
This iteration, I have migrated the app over to ASP.NET Core MVC and Blazor. With Blazor not being able to guarantee the HttpContext and reliably use session state, and a new request to support different states within different Salesforce tabs, I'm looking for new options.
I know there are multiple ways to go about this such as session storage, JS variables in the layout, C# variables in a parent component, etc. I'm curious which would make the most sense here.
I was leaning towards session storage, which I imagine is scoped to the browser tab and not the Salesforce tab. I assume I'd need to accept a Salesforce Tab Id in the SSO request to store off separate instances of session objects within the session storage, and then store the Tab Id in the layout or a parent component for later use (that is if the iframe will even have access to session storage).
How would others go about this task? Session storage, URL state, Database, variables, some combination of the latter? I'd like to avoid in-memory state to avoid any interruptions with app pool recycling or load balancing.
Related
If you have a web application with a (react) frontend communicating with a REST API, what is the best way to limit access to the views?
Let's say youre not creating a single page app, you have multiple server side routes all delivering a react frontend. These routes should all be protected via authentication, so basically even the (non sensitive) react frontend shouldnt be delivered to the client. Do you handle this on the frontend on every page? Or does that mean that i might be using the wrong tool? If you do a server side session login you would have to handle the authentication and thus especially the entity layer in two spots (limiting access to views and API). I guess you can propagate the web server login to the API or vice versa, but i'm really unsure of what is the best way to go here.
I really hope the question is not going to be viewed as "subjective".
I have a silverlight application backed by RIA services & EntityFramework. Users log in directly in the silverlight application. We have the [RequiresAuthentication] attribute on the DomainService and have implemented custom MembershipProvider/AuthenticationBase<UserBase> for custom authentication utilizing "forms authentication". All of this is working well to authenticate users.
The problem is that users with laptops using wifi will travel through the building and hand off between wifi access points. As soon as that handoff occurs, the users session is immediately terminated - with no notice to the user. I would like some way to make the session more resilient. Asp.Net's out-of-the-box forms authentication seems to do this well - as long as you are inside the session timeout and you haven't deleted your cookies, you are good to go regardless of any temporary connectivity issues. What can I do to get my Silverlight app to be at least as resilient as a standard asp.net app?
One thing that might be the issue, is that I haven't implemented many of the functions in the MembershipProvider - really only ApplicatinName and ValidateUser(). Could that be the source of my problem?
Im just in the process of putting together the base framework for a multi-tenant enterprise system.
The client-side will be a asp.net mvc webpage talking to the database through the asp.net web api through ajax.
My question really resides around scalability. Should I seperate the client from the server? i.e. Client-side/frontend code/view in one project and webapi in another seperate project server.
Therefore if one server begins (server A) to peak out with load/size than all need to do is create another server instance (server B) and all new customers will point to the webapi's on server B.
Or should it be all integrated as one project and scale out the sql server side of things as load increase (dynamic cloud scaling)?
Need some advice before throwing our hats into the ring.
Thanks in advance
We've gone with the route of separating out the API and the single page application. The reason here is that it forces you to treat the single page application as just another client, which in turn results in an API that provides all the functionality you need for a full client...
In terms of deployment we stick the single page application as the website root with a /api application containing the API deployment. In premise we can then use application request routing or some content-aware routing mechanism to throw things out to different servers if necessary. In Azure we use the multiple websites per role mechanism (http://msdn.microsoft.com/en-us/library/windowsazure/gg433110.aspx) and scale this role depending upon load.
Appearing to live in the same domain makes things easier because you don't have to bother with the ugliness that is JSONP or CORS!
Cheers,
Dean
What is the best way to maintain a user's session state in an ASP.NET MVC app hosted on a web farm?
Out application currently uses the standard ASP.NET session on IIS 6.0 but we want to move the app to a web farm environment.
I have read that we can use SQL Server session state for our application but I just want to know if anybody was using something else and why!
One way would be to use the Velocity distributed cache.
Storing session in SQL is still valid in MVC (as it was in WebForms):
http://support.microsoft.com/kb/317604
We're using it successfully across a few boxes for our MVC app, and have used it across quite a few boxes for older WebForms apps.
You could try storing your sessions in memcache. Should be both fast and scalable. It does require some memory though.
As discussed in one of the StackOverflow podcasts: usually session state is very minimal - a few keys here and there - and works well to simply store this in a central database.
I am eager to build an application with Gwt and App Engine. I'm more familiar with App Engine: creating dynamic html pages with servlets and jsp's. I'm wondering however, if this type of application technology belongs with GWT?
The two examples I can foresee being a problem are login and database retrieval.
For user log-in, my current approach is simple: at the beginning of a servlet, check if the user object exists. If it does, show the page. If it doesn't, redirect to Google's login service. How does this model fit in with GWT? It seems to me that GWT compiles into static html/javascript/css files you place on your server. With this approach, it doesn't seem possible to do any server processing to check for a vlid user before serving the static page (because any user could just bypass the servlet and type the static page url directly).
The other example would be show data from the app engine datastore. If i wanted to create a table which each row being an entry from the data store, I would dynamiclly create the html in a servlet, and do my datastore access there etc, etc. It seems with GWT I would have to serve a container html page, then use ajax to load the database content after the fact?
Maybe GWT isn't right for my type of application, or maybe I'm just thing about web application development the wrong way. Some clarification would be appreciated.
In a over simplified sense, a typical GWT app will work like this:
User navigates to your web page. Their browser uses a static url(s) to download all the javascript, css, and images necessary to run your app.
From now on, every time a user presses a button or otherwise interacts with the page, data is retrieved via an AJAX call. So yes, they might download your app before logging in, but all your security sensitive data would only be returned via an ajax call, giving you the chance to validate their identity however you wish (cookie, user/pass, etc)
This is basically what you describe in your second example about loading data from the datastore. It sounds like you think this is bad for some reason, but you don't say why.