I'll preface this by saying that I've been developing in .NET for many years, and VB/BASIC for many years before that, but my background is mostly in desktop applications and system interfaces - I'm still pretty new to all this web application stuff, so I apologize up front if this is a silly question.
That said, here's my question: when you create an object in an ASPX page and store it in cache, how can you access it from an ASMX web service that resides in the same application?
To further elaborate: I have a single web application which includes ASPX pages, an ASMX web service, and a class library consisting of two object classes. When the user signs in to the application, they configure some settings, and the objects are created and stored in a system.Web.Caching.Cache object. The custom objects are then pulled out of cache on the next page, and the user then makes an AJAX call (via jQuery) to the web service to retrieve some data.
The problem is that in the web service response, I need to parse the returned data based on the content of the user-created objects stored in the web application's cache. However, I can't find any way to access the cached object from inside the web service.
I have a sneaking suspicion that it may be possible to serialize my custom .NET objects into JSON objects and pass them via the AJAX call to the web service for deserialization, but frankly, I would have no idea how to even begin at that. Plus the objects are potentially 30 - 40K in size, and the AJAX call is being made as frequently as once every 3 seconds, so I'd really like to avoid the overhead of passing all that extra data with each call, especially since the data I need is already sitting in memory in the application where the web service resides.
So once again, I ask: when you create an object in an ASPX page and store it in cache, how can you access it from an ASMX web service that resides in the same application?
Is this making sense? Am I crazy? Missing something obvious? Any insight anyone can provide would be VERY highly appreciated. Thanks!
You can access current HTTP pipeline state using HttpContext.Current. So for accessing the cache, you need to use HttpContext.Current.Cache.
BTW, asmx web services are considered to be legacy technology (see this) - so I will suggest you to migrate to WCF services. If you go for WCF services, then you must enable ASP.NET compatibility mode (see this) to access HttpContext.
I have not tried what you are looking for but objects are stored in cache in the form of key value pairs where key can be anything from simple integer to guids and value being your object. As per my understanding the asmx service just needs the key so that it can look into the cache and returns the object. But again its my understanding not I had tried this scenario.
Related
I'm using an ASP Classic app that makes use of session state. It's got quite a few pages. I'm slowly migrating to .NET, with an ETA of about six months.
Is it worth changing over the classic asp to use a custom DB session for an implementation of that time frame? Or should I just migrate so features are separate between the apps and no session is shared?
Thanks!
In the past, I've transitioned by maintaining two apps, and passing authenication information between the two at the database layer. When the user requests access to the new ASP.Net app, write an entry into a table with guid(s) and a datetime, then redirect to an authentication page, which checks the table for the corresponding row, which is only valid for a certain length of time (30s), and has a one time use.
If the row exists, grants logged in access under the same username.
a common way of doing this, is supporting both sessions during the migration period, and letting asp.net manage authentication of all resources across asp and asp.net.
IIS 6 and higher has a feature that let's you redirect classic asp resources to aspnet handler. ( i believe this is via wild card application maps)
With this, you will get the login re-directs for not authorized sessions.
If you want to have access to .net session from asp session, a common way is to create a handler in .net (call it "/SessionSynch" for example) and than from asp, you can execute a post to it, to get all necessary session data. Something to consider here is security of course. You want to make sure that your .net handler checks the request, and only reveals session information if your request is coming from appropriate source.
you can also synchronize the info via database.
the one common identification between asp and asp.net you can rely on, is the session cookie, which is easily retrieved from both sides. If you fire up Fiddler, you will notice that upon successful authentication your session cookie will be set. you can then use this cookie from asp to retrieve session info from .net
The two things that I would take into consideration are:
Is persisting session data in a database necessary for my application?
When migrating an old application to a new platform there is a good chance you will run into some snags. Better to change the session storage at the end of the project if there is time.
If the timeline has not already been accepted and you'd just like to try and add another deliverable, this is not something that should take you very long.
The easiest way to do this (as you have mentioned it's short term only) would be to have an intermediate script (asptoaspx.asp?redirect=aspxscript.aspx) that does an automatic form post (user doesn't see it). Here is a pseudocode for that script.
Response write html form with action=aspxscript.aspx
For each session variable in ASP response.write hidden input with name=key and value=value of the session key on the form
Submit the form using javascript
This way when you go from an ASP page to an ASPX page in your application, you would have your session variables ready to use.
Hope it helps!
I have a silverlight application that uses wcf service. This application is shown from a link in an existing project of asp.net web application type. There is a userid session found in the project that i want to transfer it to the silverlight application. I thought of query string but its not a secure thing to do it. so is there a way to transfer the asp session object to the wcf application which the silverlight application communicate with?
You could write a web service that you could use in Silverlight and with which you could get and set single values from and to the current session.
If you want to transfer the whole session to Silverlight, this is of course also possible by a query parameter or the like.
Concerning security, it depends on your scenario. There is no way around that, you do have to send the data over the wire to the client in some way. You can encrypt it, but the Silverlight client will have to know how to decrypt it. Silverlight client code can of course always be inspected in reflector by anyone who has access to the application.
What you can do is set everything up to use SSL for communication, it might be sufficient for your scenario if you never send more information to a client than a client is allowed to know.
If you can run WCF services in ASP.Net compatibility mode then you would be able to share all of the ASP.Net Runtime Objects such as Session, Cache etc.
I'm building a solution where 2 applications are involved.
One of them handles the login and user management, and and other provides the service itself.
I need a way to send the user from the first app to the second, along with some data that derives from the whole login process.
The data has to be sent in such a way that it can't be tampered with; or a way to check if it's legit has to be available.
Some more details:
The solution consists of 2 ASP.NET (Webforms) websites
Although both websites are sitting on the same server, a solution that doesn't rely on this is prefered
Thanks in advance.
It might not be the best solution.
But this is what immediately comes to my mind.
Serialize the data, (from first website) that you need to pass, into a database accessible from both web sites (can be a third server in worst scenario when your both website might be sitting on different server).
Generate a key for the serialized data in the database. It can be a GUID. Pass it on to the other web site. Other website can delete it immediately after retrieving it by using the give key.
You could set an encrypted token cookie in the login application and pick it up in the management application.
I don't know of any way to transfer state data between applications on the server.
I am not if it is possible to use Server.transfer to the second site. But this would definitely be tamper-proof since it would occur on the server. The landing page on the second side would then persist the transfered info. Context object would be a good location to store the transfered info.
At a minimum it would recquire both apps to be on the same server.
I need to invalidate cache in a web application when related data is updated in another application (running on the same machine). Both applications use the same database. I know there's SqlCacheDependency.
How do is it in terms of performance?
Is interprocess communication (e.g. using name pipes) an option in web applications? Does it outperform SqlCacheDependency?
This is actually pretty simple to do by just using web services or a page action in each webapp. The web service can just clear a cached element whenever it is called.
When webapp A updates the data that is cached in webapp B, just have webapp A call the web service in webapp B that clears the cache and vice versa. You can add authentication as well if you want to secure it etc.
Anytime I have had to communicate with another web application and perform an action within the context of the other app I have done it by exposing web services or pages (ashx files) that will perform whatever action I need.
You could use a distributed cache instead, e.g. Velocity http://msdn.microsoft.com/en-us/magazine/dd861287.aspx
I am maintaining a public website (no authorization required) that uses web services over https to perform various operations. Most of the calls to the web services are invoked from javascript.
What has recently occurred to me is that a malicious hacker could, if he/she chose to, call the webservices directly in an attempt to play havoc with the system.
In reality, there is not much damage they could do, but in practice these things are difficult to predict.
Bearing in mind that the web service calls will be exposed in javascript code (which is available to the client) what is the best approach I could use to prevent unauthorized and/or malicious access to the web services.
Sadly, I can't just restrict access by IP, as there are windows forms-based client applications out there which also interact with the web services.
Using windows authentication may be difficult, as these client apps can be run from anywhere in the world and the users are not part of any specific AD Group - or even domain for that matter.
I'd appreciate any suggestions, bearing in mind the two different classes of access and the exposure of the javascript code.
Anything called by javascript can be mimicked easily by a malicious user who has the right to use that javascript. I would suggest modifying the page to use a more server-side solution. Leave AJAX to stuff that can't be easily exploited.
Preventing an unauthorized user is MUCH easier than supporting full public access. If you drop a time-expiring guid on the user's cookies, tied to the individual user, that gets sent as one of the arguments to the Web Service, you have an extra, generally difficult-to-break, layer to the application.
Anyone who has access to execute the javascript, though, should have no trouble piecing it together. Someone who has no access to the javascript can probably be kept from accessing the Web Service easily.
It takes a bit of doing, but if your page is also ASP.net you can set up a shared session, turn on the EnableSession attribute on your webservice and use session data to secure the session. An overview can be found here: http://blogs.lessthandot.com/index.php/WebDev/ServerProgramming/ASPNET/sharing-asp-net-session-state-between-we
This would necessitate a different "version" of the service for your windows apps to consume.