I've followed the advice in various places, including other questions posted on stackoverflow about sharing the session state between a WCF service and an ASP.NET website, but cannot get my specific scenario to work:
The website and WCF service are both virtual directories of the same application in IIS 7 and both share an app pool. The website stores some data into the session. A flash object rendered on the client makes a call to the WCF service. I would like the WCF service to be able to access the data in the session.
I have put the [AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Required)] attribute on the service class, and I have the following lines in the web.config for the service:
and on the binding I have allowCookies="true".
All server side code is written in C#.
However, when using HttpContext.Current.Session from the WCF service, I find that there are no keys stored in the session object.
I have checked with Fiddler, and the flash object definitely passes through the ASP.NET_SessionId with the same value as requests to the website from the browser use.
Can anyone shed any light onto how I can make this scenario work?
Thanks.
Check this:
http://msdn.microsoft.com/en-us/library/ms731193.aspx
Related
I've got a legacy ASP.NET soap web service on my computer. The service has this annotation:
[WebMethod(EnableSession = true)]
on several methods and uses the Session property to save some information:
Session[CONSTANT] = some_value;
This value is preserved when I call different methods of the web service one after another in a browser (both Chrome and Internet Explorer) but NOT when I call the service methods from a proxy created in Powershell or in Visual Studio.
Do I have to set some parameters on the client to preserve the Session?
On another computer the same service is installed and there the value stored in the Session is NOT preserved between method calls, not even in the browsers. Do I need then to change some parameters in the web server in this case?
In both cases the web service is hosted in IIS.
The following has done the job for me:
adding a legacy web reference instead of service reference.
using the SoapClient.CookieContainerlike in
Implementing session in SOAP Client
I have a challenge and I believe there is a developer smarter than me that can provide some insight.
I have a web service. This web service is written with ASP.NET MVC in C#. I want to allow developers to call this web service. When developers are writing code, I recognize that web apps typically run from localhost. When they call this service, I want to be able to identify if the request is coming from localhost. However, if I look at the IP address, its the IP address of their machine.
Is there a way for me to even do this? Clearly Request.IsLocal won't work as my web service is running on an entirely different machine.
When you call a web service, the browser usually passes the page in the Referer header. So you can check if that value starts with "http://localhost". Virtually anything in an http request can be forged (including this), so be careful what kind of decisions you make based on this data.
Without passing some additional data along with the request from the app, there's not going to be any way for you to know.
You'll only be able to get the IP address or Host name that was used to make the request to your Web Service and it sounds like you want to be able to find the Host Name (localhost) that was used to make the request to the app (which then triggers the call to the Web Service).
How will you then define local (from the perspective of your service)? You'd be better off setting up a development service on a different API end point instead of attempting to guess this.
All production level API calls can go to something like api.yourservice.com with all development level requests coming in via dev.yourservice.com.
You can then have two separate services or have your service read the URL being requested and differentiate based on this.
Hi stackoverflow users.
My server setup is the following:
A webserver with access on http/80 running www.domain.com
A app server with access to the internal network (db etc.) running a webservice
I have this simple little server setup problem.
Now I want to call my webservice from a ajax script from a website on my webserver. But since my application server does not have access to the internet this will (in my mind) not be possible since the javascript (running in the end-users browser) shoud have access to that webservice.
I came up with the solution by inventing a webservice on the webserver calling the webservice on my application server, but thats a odd solution, does any of you have a idea how to solve this?
I don't think you can do this. You will have to provide some thing on WebServer using which end user can access your App Server.
You have multiple options for this
PageMethods
Web Services on WebServer which will relay ajax calls to the App Server
Hope this info helps you.
If I understand correctly, you are just just using a webservice as a proxy through some network firewalls. There are tools that will do this for you, however, if you are running a simple service, then I don't see a problem with your setup.
One such tool for IIS is Application Request Routing
I have simple asp.net webservice has login method and its deployed on IIS server url is http://sitename.domain.org:9111/membership/membershipdir.asmx.
My network team created a SSL proxy url on proxy server (i think it is apache) for this web service site.Now webservice can access through proxy like this https://www.domain.org/webservices/spws/Membership/membershipdir.asmx.
It works fine but when I invoke the webservice method. the result window url showing on http://servername.domain.org:9111/Membership/membershipdir.asmx/Login
Now network team complaining the port 9111 still exposes to public for the login portion. something has to change in application. I am not understanding what should I change in application level.
I am also not understanding why results on showing with server name without proxy name?
Anybody have any clue?
Check out: What's the best method in ASP.NET to obtain the current domain? to always use the same domain the user made the initial request to.
Now, I'm not sure about the proxy server situation... if the proxy server is making any changes, it should be doing the opposite on the way back out... so I really can't speak to that problem... but, regardless, make sure you are using the original request domain by either using relative paths, or by the method in the Question linked to above.
I'm building a complex, public web service in WCF that send email to a specific address, similar to a contact form but with some features.
With jQuery I get the data from the textbox and with Ajax and json I send to the web service the strings to proceed at the send.
Now, is there a good way to make it secure?
I mean.. the service is public so someone can have access to it and starting to spam on this address. Can I restrict the users to use the web service only from the correct web site?
Thanks.
IF the WCF service is hosted in the IIS you can allow calls only from a specific IP address, look at the directory security settings under IIS.
By far the simplest way is to have your web service require some type of access key in order to run the operation.
Something simple like a base64 encoded GUID would work. It doesn't even have to change. Just add a parameter called "AccessKey" or something similar. Have your app pass that and let the service validate that it is good.
Another idea is to have the web service check the http headers to see if it came from the page you authorized to use it.
Neither of those are perfect. The first one means that your "key" will be inside the html you send to the client. The second one can be spoofed.
Personally, I'd probably not bother at this level and just log what the service is doing. If the traffic counts to the service start to exceed what you think it ought to be, then I'd investigate ways to mitigate it. Most likely, given that it's a service you won't see any issues.