I need to get the calling app's URL because the service sends emails that contain links to my app (e.g. click here to view the form).
I'm considering just hard-coding the app's URL in 1 place on the service, but when working locally the local host port will sometimes change. Also, when deploying to different test environments I would have to change the URL. Also, working with others will pose a slight problem too.
The best solution would be to determine it dynamically. Second best, web.config. Third best: hard code it.
How can I resolve this and get the calling app's URL?
Edit: it's impossible to send the url from the client because the service has a timed event to send email notifications.
maybe the IP Can help
try this line
((RemoteEndpointMessageProperty)OperationContext.Current.IncomingMessageProperties[RemoteEndpointMessageProperty.Name]).Address;
this article can help on the long way
http://keyvan.io/detect-client-ip-in-wcf-3-5
EDIT
getting the URL is not possible,
Similar question here
Can I get the WCF Caller Url...?
Related
I'm a bit out of my depth and haven't found the answer I need from Google, so could do with some advice.
I have a website that currently has some functionality build in.
I now find myself needing to create a second website containing the same functionality.
In order to do this the proper way, I want to create a webservice and access it from both sites. I've created a new solution and the webservice so far.
On my development machine, I can browse to the webservice.
The question is when I move this webservice to the live server, will it need it's own IP address, domain, or both? Or can it reside on the local server and be accessed in the same way as I would on my development machine?
The webservice does not need to be accessed from outside the server.
I'm a little unclear and its not easy to test in a live environment.
All help appreciated.
A web service works in exactly the same way as a website, only instead of returning HTML, it returns JSON/XML or similar. You'll need to host it on a web server, but if you only need it to be locally accessible, you can set the web server up to bind to localhost (127.0.0.1 in IP4) either on the default port (80) if nothing is already using it or on a different port (eg.12380 where it would be addressed as http://localhost:12380).
Most web servers can bind to anything that comes in on a specific IP address that isn't otherwise allocated or they can recognise which site to serve based on the host name that has been requested. nb. the host name isn't sent automatically by (TCP/)IP - the browser, or in this case web service client will sent an HTTP request header to let the server know which site to serve.
If you have sufficient control over the server, you can also create an entry in the hosts file to use in place of a domain name (eg. webservice maps to 127.0.0.1) and then set up your web server to bind to that.
I can usually test my web application on my PC. (In "production" it's on a web hosting server.) But now I have a callback page (.ashx) and am not sure how to proceed - How do I have my application receive the callback? Is there some way to have the callback page redirect to my PC? Some way to have my PC receive callbacks and specify the callback address as my IP (I can chose any callback url I want.)? Maybe some other way?
I don't need to actually attach it to the debugger, only to see the results.
If your ASHX file is in an ASP.NET Web application or website, you can host it locally with IIS or visual studio and then call it with Fiddler (www.fiddler2.net)
Using fiddler you can make calls to your ASHX and pass any payload required.
I don't know your network environment, but depending on how flexible it is, you could set up dyndns or a static domain so that your callbacks actually reach your PC.
I don't love it, but it's a logical solution. Then once you've got everything working properly, you update the domain in all of your call backs to point to production, and you should be ready to go.
I use wcf ui services communicate between my javacsript (jquery) and server side code. I find this work effectively.
However I want to make it more secure. I can I set up wcf so that the requests to the services can only be made from within the same domain, to prevent external clients from making such requests to my services.
So for example, my service opertion url is http://www.website.com/Service.svc/GetProducts. I want to set up wcf so that only requests from pages in the http://www.website.com are allowed. I presume this is in the realm of cross domain wcf requests but need some assistance in setting this up. Help would be great.
This simply isn't possible if your services are exposed to the web.
If something about your services isn't secure enough for that, you should look into fixing that problem - not trying to prevent people from making requests.
Anyone can always use a debugging proxy like Fiddler, Charles, etc. or a tool like WireShark to send any data they want to your services - including a complete replay of a request made via the browser. (Including referrer http headers, etc).
If your situation allows for it, perhaps you might consider using a VPN appliance or something similar, and restrict access to users inside your network (or coming in through the VPN). That way there is less concern about your security of the services.... however it's a known fact that "internal attackers" are just as prevalent, if not more so, than external ones... so don't get too comfy.
Let me head this argument off at the pass too, while I'm at it; someone might suggest that browsers already prevent cross site scripting like that. Yes, that's true. But usually it would be the developer of the other application adding the client side script to call those services - and he/she could just as easily make that request on the server side and proxy the results along to the client.
I am planning a SaaS system, to be written in C#, ASP.NET using WCF that has two separate components:
On a static IP web server in the cloud will be a web app, common to all clients.
Inside each client's office will be another app, installed on a server with IIS.
The site app will obviously be able to connect to the web services published on the web site. But here's the rub - I also want the web app to be able to initiate a connection to the site app... and the on-site server may not necessarily have a static IP. I can't control this, because we may have hundreds of clients at some point in the future, and we cannot limit our saleability by insisting that the customer has a server with fixed IP.
So, how to do this?
I could have the site apps "checking in" with the web every minute or so, to give the web app the possibility of responding with a "while you're here, please do x,y,z..." but that seems very inelegant. Also, if we're talking about hundreds of clients, I don't want to be bombarding my web server with all these "hi there!" messages if they're not actually required.
Is there a better way?
WCF? Here we go:
Use a message based approach (exchange message, no stateful method calls).
Clients connect to the server. Establish a HTTP-based TWO WAY CONNECTION. This way the server can call back to connected clients. This is standard WCF stuff and works well through NAT with version 4 of the .NET framework.
Voila. In case of a disconnect the client can re-connect, re-identify himself and gets the pending messages.
IIRC "push communication" is done by letting the client do a HTTP Request with an indefinate timeout. Then the server responds when he has something to say. After the respons the client immediately makes a new request.
It works out the same way like the server is making the connection and takes far less resources than polling.
Dynamic DNS is one possibility, but depends on your clients/customers.
If the site app is created by you, it only has to contact the web server when its address has changed (or when the site server/web app is restarted). Still, a keep-alive heart beat of, say, every 30 min. to 1 hour isn't a bad idea.
Edit: I think SNMP services may provide the answer but I'm not a networking expert. You'll have to do some digging or ask a separate question on stackoverflow.
What would you say about Comet technology?
Sounds like you'll definitely need some sort of registry on the server, then it could attempt to call out to the client apps if it needs work doing.
Generally it is client apps that check in with the server every X seconds - this is how Selenium grid works anyway. With a central hub with which clients register. When the hub receives a request to run some tests it passes the jobs out to the clients to perform.
You may not need the "checking in". The server could just attempt to call out to a registered client app until it finds one that is available.This way only the server would need a static address (could use a DNS name instead of an IP to make it more robust).
Also have a look at XMPP PubSub. This could be a more robust and standardised way to handle this.
In the end I decided to go with NetTcpBinding, for reasons best given by #Allon Guralnek here. It's worth clicking through and reading what he has to say...
On the client machine I need to be able to somehow detect which sites the current user are looking at right now.
I know the base URL of the sharepoint app, say sharepoint.thecompany.net but how the hack do I get the last requested url from the server?
I have hit a dead stop when trying to iterate the current processes and the casting the iexplorer process to something I can work with, I just don't know which kind of object to cast the process to :-(
I hope to implement this logic in a C# assembly what should run on the client box.
Any other approach that might work?
Thanks in advance
WatiN will allow you to attach to IE instances and get the current url from them. It will also allow you to do the same with Firefox instances.
It might be more efficient however to try to get requested urls at the network level using a wireshark type concept where you are just listening to http traffic on the computer and keeping track of the urls but a solution like that is a bit over my head.
EDIT: I came across this while looking for a solution: http://www.codeproject.com/KB/IP/networkmonitor.aspx
From what I can see I would think you could adapt the monitoring code to monitor and look for http request packets and parse the headers for the url information you need.