I have some shared server web hosting in the States (I'm from the UK), which allows me to publish PHP and .NET applications. I cannot install my own software onto the remote server, but I'd like to set up a web forwarding proxy for accessing sites that serve different content depending on what country you're from.
My C# and ASP.NET skills are OK, but my PHP is very limited. Are there any solutions that anyone would recommend for this sort of problem? The proxies I've investigated all seem to require installation on the server machine itself, whereas I'm just looking for something that's accessible from a URL.
Obviously, as the requests are coming from the UK, the headers will have to be manipulated by the proxy before forwarding them on. I was going to code my own HTTP handler in C#, but I don't want to reinvent the wheel if there's something out there already ;)
Although quite old, the Org.Mentalis.Proxy could be a good starting point for an example proxy implementation in C#. You can find it here: http://www.mentalis.org/soft/projects/proxy/
maybe this script is helping you? phproxy
Related
I'm searching for a way of authentication like that from Blizzard (Authenticator). It creates an off-line OTP.
I know that larger companies use it as "tokens" however, I'm still unable to find a proper library.
So, what I want;
A project that is able to create OTPs on the client side without having the client to connect to the internet and yet be able to generate the exact same on the servers-side.
I think you can take a look at this library: https://code.google.com/p/otpnet/
It is a C# port of a popular TOTP/HOTP for PHP. There seems to be a few outstanding issues in the library which have not yet been fixed by the developers but you can easily patch it on your side with recommendations that have already been submitted.
I am thinking an HttpModules for IIS, a Pre and Post request handler and some custom module for Apache.
Please only suggest Open Source, we will need to modify the projects.
We want to run these on our high volume production systems so tools that emphasise debugging is not what we are looking for. We want the simplest capture paradigm.
We want to capture data for particular web sites, not for interfaces so I am not looking at packet sniffers.
We would prefer an in-process solution which means avoiding wire-shark, squid or other proxy based solutions.
A nice to have would be the ability to replay a stream of requests in another environment, but I am confident we can build this ourselves if we can capture the requests in a sensible manner.
Any ideas, suggestions and questions will gladly be entertained.
A proxy server that logs is best, but you've already ruled that out. Outside of that, you need a product per web server. For IIS, yes, an HttpModule is the way to go. To replay them, that's likely a carefully crafted log viewer. This is typically a feature of a proxy server. Even Fiddler has the ability to capture and replay.
I have recently created an API on my server in PHP, but I have discovered that I shouldn't use my API directly with an API key because sensitive information like that can't be held securly inside an EXE. I did some research and people recommend creating a proxy between the API and your application, but even still that can be broken into.
I was wondering, how can I make my server know if it is being accessed from my C# application, or from another source? The reason why I want to know is to stop potential hackers accessing my gateway and using it themselves.
Thanks
SSL with a login?
There is no way for you to be certain someone is using your application to access a web service. I'm in a similar boat, and the most you can do is ensure the communication channel is secure (SSL) and use a username/password or something similar. You also have to be aware that anything done on the client's computer can be compromised. So much so, that you should pretty much assume that your application will be open source to anyone that wants it.
I have code on my server which works very well. It must crawl a few pages on remote sites to work properly. I know some users may want to abuse my site so instead of running the code which uses webclient and HttpRequest i would like it to run on client side so if it is abused the user may have his IP blacklisted instead of my server. How might i run this code client side? I am thinking silverlight may be a solution but i know nothing about it.
Yes, Silverlight is the solution that lets you run a limited subset of .NET code on client's machine. Just google for silverlight limitations to get more information about what's not available.
I don't know what is the scenario you're trying to implement, and whether you need real-time results, but I guess caching the crawl results could be a good idea?
In case you're after web scraping, you should be able to find a couple of JavaScript frameworks that for you.
I think your options here are Silverlight or somesort of desktop app
Unless maybe there is a jquery library or other client scripting language that can do same things
That's an interesting request (no pun). If you do use Silverlight then maybe instead of porting your logic to it, create a simple Proxy class in it that receives Requests from your server app and shuttles it forward for the dirty work. Same with the incoming Responses: have your Silverlight proxy send it back to the server app.
This way you have the option of running your server app through the Silverlight proxy in some instances, and on its own (with no proxy) in other scenarios. The silverlight plugin should provide a consistent API to program against no matter which browser it's running in.
If using a proxy solution in the web browser, you might even be able to skip Silverlight altogether and use JavaScript/AJAX calls. Of course this kind of thing is usually fraught with browser compatibility issues and it would be an obscure push/pull implementation for sure, but I think JavaScript can access domains and URLs and (in some cases of usage) not be restricted to the one it originated from.
If Silverlight security stands in the way you might look into other kinds of programmable (turing complete) browser plugins like Java, Flash, etc. If memory serves correct, for the Java plugin, it can only communicate over the network with the domain it originated from. This kind of security is too restrictive for your crawling needs.
I would like to have a client-server application written in .NET which would do following:
server is running Linux
on the server there is SQL database (mySQL) containing document URLs
What we want:
- server side would regularly crawl all URLs and create a full text index for them
- client side would be able to perform a query into this index using GUI
The client application is written in .NET using C#. Besides of searching in documents it will be able to do a lot of other things which are not described here and which are done client-side very well.
We would like to use C# for the server side as well, but we have no experience in this area. How are things like this usually done?
Clarifying question now based on some answers:
The thing which is most unclear to me is how client-server communication is usually handled. Is client and server usually using sockets, caring about details like IP addresses, ports or NAT traversal? Or are there some common frameworks and patters, which would make this transparent, and make client-server messaging or procedure calling easy? Any examples or good starting points for this? Are there some common techniques how to handle the fact a single server is required to server multiple clients at the same time?
To use c# on Linux you will need to use Mono. This is an open source implementation of the CLR specification.
Next you need to decide on how to communicate between server and client, from the lowest level of just opening a TCP/IP socket and sending bits up and down, to .Net remoting, to WCF, to exposing webservices on the server. I do not know how compleat WCF implementation is on mono, also I think you may have issue with binary remoting between mono and MS .Net .
I would suggest RPC style WebServices offer a very good solution. WebServices also have the advantage of alowing clients from other platforms to connect easily.
EDIT
In response to the clarification of the question.
I would suggest using mono/ASP.NET/WebServices on the server, if you wish to use c# on both server and client.
One assumption I have made is that you can do a client pull model, where every message is initiated by the client. Using another approach could allow the server to push events to the client. Given the client has the ability to pole the server regularly I don't consider this much of a draw back but it may be depending on the type of application you are developing.
Mono allow execution of c# (compiled to IL) on a Linux box. Mono ASP.NET allows you to use the standard ASP.NET and integrate into Apache see http://www.mono-project.com/ASP.NET and finally WebServices allow you to communicate robustly in a strongly typed manner between you client and your server.
Using this approach negates most of the issues raised in your clarification and makes them someone else's problem.
Sockets/SSL - is taken care of by standard .Net runtime on the client and Apache on the server.
IPAddress/ports/NAT traversal - Is all taken care of. DNS look up will get the servers IP. Open socket will allow the server to respond through any firewall and NAT setup.
Multiple Clients - Apache is built to handle multiple clients processing at the same time as is ASP.NET, so you should not encounter any problems there.
As many have already mentioned there are a number of thing that you have mentioned which are going to cause you pain. I'm not going to go into those, instead I will answer your original question about communication.
The current popular choice in this kind of communication is web services. These allow you to make remote calls using the HTTP protocol, and encoding the requests and responses in XML. While this method has its critics I have found it incredibly simple to get up and running, and works fine for nearly all applications.
The .NET framework has built in support for web services which can definitely be called by your client. A brief look at the mono website indicates that it has support for web services also, so writing your server in C# and running it under mono should be fine. Googling for "C# Web Service Tutorial" shows many sites which have information about how to get started, here is a random pick from those results:
http://www.codeguru.com/Csharp/Csharp/cs_webservices/tutorials/article.php/c5477
have a look at Grasshopper:
"With Grasshopper, you can use your favorite development environment from Microsoft® to deploy applications on Java-enabled platforms such as Linux"
Or see here
The ideea is to convert your app to Java and then run it on Tomcat or JBoss.
Another approach: use the Mod_AspDotNet module for Apache, as described here.
This Basic Client/Server Chat Application in C# looks like a kind of example which might be a starting point for me. Relevant .NET classes are TcpClient and TcpListener