I am looking for a way to have ColdFusion and ASP.NET share session variables. I have seen posts in the past saying that you cannot do this directly with out calling some sort of ColdFusion function to return some sort of string representation of the session. I have recently learned about something called ehcache that is a third party session storage tool. That got me wondering is there a third party session tool that will allow ASP.NET and ColdFusion to share a session.
Some details about our systems:
They are running Windows Server 2008
We are using IIS
We are using ColdFusion 9
ColdFusion/Railo and asp.net can use EHCache, but they're very unlikely to share sessions out of the box. Each will have their own session key, which they'll use to put the data in/out. They'll all have their own way of storing the data. I may be wrong, but from memory, ColdFusion uses WDDX, Railo uses something like JSON and I've no idea what the .Net platform uses.
The point is that each hides the complexity of dealing directly with ehcache, but they each do it in their own way. If you want to interoperate, you may need to have each read/write directly to ehcache (or the database). You'll also have to work out a way of sharing a common key between .Net and ColdFusion.
If you're rolling your own version of this, then using JSON proably makes sense as the common format.
Related
I have to different ASP.NET applications (same version) running on the same IIS Server and I have Sessions running In Process. Will the session state/variables persist across the two applications? I found a similar post where someone asked the same question but they were managing sessions in SQL Server and someone pointed out explicitly that session state doesn't persist (out of the box) across two applications of Sessions were maintained using SQL Server. It made me wonder if the same applies by default for two applications where the sessions are maintained in process.
No there is custom code needed.. best way that I found to do this.. is to have the referring page pass its session id and application name, then SQL stores the Session Data in a table using the [sessionid][appkey]... we use a reference table that I manually build to figure out the appkey for each new application... then I wrote a DLL that takes the string in and pulls the sessiondata from the DB and packs it in to the new pages current session.. Its a little tough to wrap you head around, but I can supply the DLL and how to use it if you want. Just PM me and ill get that DLL for you.
Back in 2008 I remember running into a 3rd party tool that did 99.9% of the work of implementing task/role security. From what I recall it was simply an extension of what was built into .Net. You ran a script to add all the needed tables to your SQL Server then used the UI to go in and define all the tasks and then grouped the tasks into roles. The assigned users to a role. The power was that different roles could have the same task and it was all configured by the UI tool that came with this system. I also thought it was on CodePlex, but I don't recall the name. All I recall it was Microsoft's name with like Sql or something added to the name of it.
At the time, 2008 (VS2008 days), I was told by co-workers that Microsoft was slowing consuming the whole system into .net.
Anyone have any idea what the name of the thing was I am thinking of? Is it part of Microsoft .Net now?
Are you perhaps thinking of NetSqlAzMan, which uses a similar authorization model to Microsoft AzMan? Or perhaps you're thinking of AzMan itself, which has a UI and allows storage in SQL Server?
Background
We have a large asp.net application and uses a lot of sessions like datasets, datatables etc.
We want to support web farms for this application, so we want to save the session state in sql server.
I am successfully storing all the required data into the sql sever and getting all the data fine as well.
Our supported database is SQL Server 2005-Sql Server 2008.
We have to store datatables and datasets in sessions, even we know it is going to be bit expensive.
Question
I want to know from other developers is there any advantage of using Custom Store Provider to store data. (any help in debugging or error finding or future proofing etc.)
Or i just change the web config and make all the classes serializable to make it work.
Any custom way to make all the related classes serializable using c# code.
Any better way to intervene the process used by .net to store data in sql server (default process on changing web config)and make it better, by changing one or more classes.
Thanks,
I would go with marking your business objects as [Serializable]. I think it should be a lot leaner than storing datatables/datasets.
The best way to make your classes serializable is to simply decorate them with [Serializable] I don't think you need anything else besides that.
If you use a load balancer with sticky sessions, I would actually go with LocalStateServer as it should perform faster than SqlServer
I think you can go for your point 2.
there is no magic/automated way to change all your classes to be serializable, either you use the attribute way or the interface way but in some classes you could need some fixes or changes depending on what are the property types.
apart from that everything should work smoothly once everything is Serializable and yes, you touch the web.config and all should work.
if some of those objects are non user specific but can be shared among users, a possible alternative could be appFabric, if you configure a cache cluster (which could consist in multiple machines), you can then save objects in that cache, but as I said before this depends on your application, are those objects absolutely user specific so MUST be in the session and not in a shared cache? have a look at this answer: AppFabric vs System.Runtime.Caching
What would be the pros and cons of taking a large (16000 LOC) existing Access 2007/Forms application and porting it to SQL Server 2005, while keeping the Access forms on the front end, versus porting the front end to a .NET technology, say ASP.NET 4.0 or MVC3? The backend is definitely getting ported to SQL Server, with large schema modifications, so this question is about whether to use the existing Access Forms front end or not. I don't take throwing away existing working code lightly! On the other hand, the schema will be changing a lot.
If you had a lot of experience with ASP.NET/Oracle but not with Access or SQL Server, how might this change your answer?
Thanks,
Mike
There is nothing wrong with Access as a front-end to an RDBMS whether SQL Server or another
Porting the front-end but leaving an Access back-end would seem a bit weird: why bother? Access is a good presentation tool but mediocre DBMS. Why keep the mediocre?
Also, only change one component at once no matter what you do: data, then front end. Don't do a big bang approach and change the lot
Actually, comparing going with web application (ASP.NET) and stand-alone (Access) is not truly "apples-to-apples" comparison. It highly depends on your requirements.
Sure, going with web application will require much more developer's efforts comparing to building forms/reports in Access. But, the pay-off will be felt in the mid to long term.
You should also consider scalability, deployment, and availability issues when deciding to go/stay with Access.
I just discovered ASP.net uses its own profile system to register users and there seems to be a lot of features available as bonus with it (such as secure authentication). However it seems rather specific to have such a feature for a general purpose development environment and things which work in the background the way the profiles system does without me really knowing how (like where the user data is stored) kind of scares me.
Is it worth developing a website which requires user authentication using the asp.net profile system or would it be better to develop my own using SQL databases and such? I'm not going to avoid using SQL anyway, even if I use profiles I'll use the profiles unique ID to identify user data in the SQL table so in that sense I'm not going to avoid using SQL for user information at all.
My favorite thing about profiles is that you can create custom permissions in Web.config files using them () and avoid having to type in the same code to the top of all your aspx source files to do the authentication check.
The other thing I kind of like about it is that security is built in with secure authentication cookies, so I wouldn't have to deal with them myself.
But it doesn't seem like that big of a deal really. I'm just confused as to where profiles stand as far as ASP.Net development goes and what they're designed to accomplish.
The Profile/Membership and Role provider API is very intertwined, and specifies things very narrowly. The benefit is that there is little you have to do to get a lot of functionality working. The disadvantage is when what you need doesn't match what is provided. Nevertheless, there are many potential gotcha's that the API takes care of for you that it really does make sense to use it, at least for authentication.
My needs did not match what the API provided, and I really only needed the Membership portion. The problem is that I had a piece where I needed to use the same authentication and authorization across a web application and a desktop application. My needs are pretty unique, but it's designed for a classroom setting.
Getting the membership to work for my needs wasn't that difficult. I just had to implement the Membership API. There are several features I just didn't need with the Membership API like self-registration, etc. Of course this did present me with a challenge for role management. Typically, as long as your user object implements IPrinciple it can be used directly--but there are serialization issues with the development web server Visual Studio packages if your user class is not defined in the same assembly. Those problems deal with serialization, and your choices include putting the object in the GAC or handle cross-appdomain serialization yourself with objects that are in the GAC like GenericPrincipal and GenericIdentity. That latter option is what I had to do.
Bottom line is that if you don't mind letting the API do all the management for you, than it will work just fine. It is a bit of smart engineering work, and attempts to force you down a route with decent security practices. I've worked with a number of different authentication/authorization APIs (most were not CLR based), and the API does feel a bit constraining. However, if you want to avoid pitfalls with session/state/cache management you really need to use the API and plug in your own providers as necessary.
With your database, if you need to link a user with any database element you'll be storing the user's login id (Context.User.Identity.Name).
You seem to mix the Profile/Membership/Role provider API. But to answer your question: why not use it? I would use it unless there is a real constraint that makes it unusable...