How can I specify detailed proxy settings in TweetSharp? By this I mean in addition to the server name, details like Port, Username, Password etc? As of now the only parameter, is
Dim X as New TwitterService(Key,Secret)
X.Proxy = "abcd"
Which accepts only a string, which I assume is the server name / IP Address.
My app is behind a corporate firewall and the proxy requires authentication and uses a custom port. Any ideas?
As I was completely unable to specify the authentication details for the proxy server, I was forced to come up with my own workaround. I installed ccproxy on the server, and had it cascade the authentication to the other proxy server.
This is working well as of now.
Related
In one of my applications (ASP.NET/VB.NET), I need to read the Client Machine Name. Based on the Client Machine we trigger a Point of Sale payment device to accept the payment. On each of these systems we have a stand alone software installed which communicates to the bank using HTTP requests. I am using the following .NET code to read the Client Computer Name.
Dim name As String = String.Empty
Dim hostEntry = Dns.GetHostEntry(HttpContext.Current.Request.UserHostAddress)
If hostEntry.HostName.Contains(".") Then
name = hostEntry.HostName.Substring(0, hostEntry.HostName.IndexOf("."))
Else
name = hostEntry.HostName.Trim
End If
In the development environment, all our systems are in a domain ("xyz.com") and we don't have any issues. In the customer location they don't have a domain name setup. My above logic works well in some of the systems in the client environment and is able to make payments but in most of the systems our logic fails and is not able to read the host name. Any help will be appreciated.
Your question doesn't have the specifics required to answer your question. There are many questions that need to be answered about both environments to give a correct answer. Since I can't ask questions, I will make some assumptions which might apply to future readers of this post and be able to help them out.
I would ask a question but my profile was forked for some unknown reason and I don't have the required reputation to ask a question. That being said I will run through the list of issues I can identify off the bat and suggest solutions for the issue and hopefully one will lead you to a solution.
So...
1) You state you need to read the client machine name. However, if your application isn't running on an internal LAN (aka an intranet) you can't read client machine names period. So this could be your first problem.
2) Combining point 1 and given that you are reading the IP Address from UserHostAddress of the client to look up a DNS host name and when the host look up succeeds you are taking the first part of the name up until the first "." it should be safe to assume that this an intranet application running on a LAN in both your development environment and at the client environment. With that assumption and given the statement that all machines are given an domain of xyz.com it can be assumed that DNS in your development environment is being dynamically updated from presumably through Active Directory (AD). In such case, whenever a client machine on development network requests an IP address, presumably through AD, the DHCP server integrated with AD issues the new IP Address. When it does and the DHCP offer is acknowledged and accepted by the client AD updates DNS (which on a windows network is also AD integrated) by adding a host entry with the computer name of the client machine pointing to the IP Address. Additionally a DNS pointer, depending on configuration, can be added to AD's DNS which allows an IP Address lookup to resolve to the record (which in this case would be the Client's machine name). So with your development environment (presumably running on Windows Active Directory Domain) everything works. Addi tonally, by default the top level domain name (XYZ.COM) gets appended to the clients computer name in initial DNS requests from the client.
3) Your client is not running a domain which leaves further questions. Are they running windows? If they are running windows is it as a non-Ad environment, for example a work group. First assumption would be they are not AD integrated or otherwise you most likely wouldn't be having this problem although I can think of a few rare case scenarios where they might. However, odds are the relevant questions are What DNS server are they running and what DHCP sever are they running? Your application is trying to use a client IP Address on their network and the host name lookup based on their IP is failing so it tells me in their environment for one reason or another you can't get a host name from the IP Address of the client. Mind you if they could be on AD and configured entirely correctly their DNS server is just overwhelmed and not responding within 2 seconds causing the name lookup failure but that is the rate case. With more information I could help more.
3) Assuming in 2 that they are not on AD, do you have the ability manually code host names on the computer your application is running? For example, lets say yourapp.exe runs client-server-01 and clients connect to it. Then on client-server-01 you could add static DNS entries in the host file for each PC on the client network that you expect to connect. On the other hand if your application is running locally on the client PCs you could pass the machine name as a header in the web request and then read it from the Request.Headers variable on the server.
4) Again, making another assumption the clients are web based and your application in the client environment is being hosted on the server... Is the server on a DMZ outside the client environment? If so the client environment may likely be configured, per best practices, that the server host your web app is in a DMZ and DNS requests to the box are forwarded to the client's ISP and not back into their network that has the DNS server capable of resolving an internal IP to a client machine name. If this is the case you need to send the client machine name as a variable from your client or code local IPs to host names in the servers host file (assuming the internal network isn't behind NAT and exposes the real client machine's IP) or request that the DMZ'd server can access the internal DNS and configure the access accordingly.
....
The list really goes on and on but I think I highlighted the problems for 99% of the situations and provided answers to their various solutions.
You can try to take it from X-Forwarded-For header
The X-Forwarded-For (XFF) HTTP header field is a common method for
identifying the originating IP address of a client connecting to a web
server through an HTTP proxy or load balancer.
This is what X-Forwarded-For should return:
X-Forwarded-For: client, proxy1, proxy2
Here some example code:
string ip = Request.ServerVariables["HTTP_X_FORWARDED_FOR"] ;
if (!string.IsNullOrEmpty(ip))
{
string[] ipRange = ip.Split(',');
ip = ipRange[0];
}
else
{
ip = Request.ServerVariables["REMOTE_ADDR"];
}
There was an issue with Firewall setup on the client machine.Due to that our .NET code was failing. After adding an exception to all the incoming requests from xyz.com. My code is working without any issues.
Thank you guys #Alexander Higgins, #halfer for the help.
I am trying to connect to an instance of Active Directory Lightweight Directory Services 2008 R2 via a secured SSL connection from a .NET 4 web service, and I'm getting "The server is not operational." error.
I am using a user which was created using the ADSI Editor and placed in the Administrator Role.
I am able to login/connect via ADSI editor with this user using SSL and simple binding, and
I can connect with the web service using the same user credentials but using the non-SSL port.
I am using the distinguished name and
the user is definitely not inactive.
Here is the code that I use to bind:
DirectoryEntry entry = new DirectoryEntry("LDAP://2.2.2.2:636/DC=nfa,DC=local");
entry.Username = "CN=ldapadmin,DC=nfa,DC=local";
entry.Password = "P#ssw0rd";
entry.AuthenticationType = AuthenticationTypes.SecureSocketsLayer;
I have tried it like this as well:
DirectoryEntry entry2 = new DirectoryEntry("LDAP://2.2.2.2:636/DC=nfa,DC=local", "CN=ldapadmin,DC=nfa,DC=local", "P#ssw0rd", AuthenticationTypes.SecureSocketsLayer);
The server needs an SSL certificate installed that meets the documented requirements. Test connectivity with LDP. You will need to connect using the fully qualified domain name of the machine. Replace the IP address above with the FQDN and you should be all set.
As #ColinBowern mentions you need to provide the Fully Qualified Domain Name (FQDN) instead of the IP since the certificate was issued to the FQDN.
First, verify that the certificate registered with the AD LDS on the remote machine is correctly installed:
Run certmgr.
Verify the Certificate Authority (CA) that issued the certificate exists in the Trusted Root Certification Authority\Certificates store.
Verify the certificate exists in the Personal\Certificates store with the correct FQDN (the domain name of the remote machine), issued by the above CA and of type "Server Authentication".
Second, the FQDN might not resolve correctly to the remote machine due to a DNS registration error. Verify that the hosts file (located at C:\Windows\System32\drivers\etc) for the local machine maps the correct IP to the FQDN (as shown in the certificate name). If no entry exists, it needs to be added,
192.168.1.34 domain.name # <-- FQDN as shown in the certificate
Connecting to a named Active Directory server in the DMZ (i.e. not in the domain), over port 636 using DirectoryEntry then pulling attributes using DirectorySearcher.
String
string serverPath = "LDAP://some.domain.com:636/OU=XXXX,DC=xxxx,DC=xxxxxxxxx";
var searchRoot = new DirectoryEntry(
serverPath,
User,
Pass,
AuthenticationTypes.Secure);
The first query is very slow, around 22-25 seconds. It was explained to me that this may because IIS 7.5 may be doing a look up of the certificate on the AD server against a CRL, but not getting a response. Then, subsequent queries accept that answer until the process times out, so that the next query will again take 22-25 seconds.
Is the type of connection that I've described in my code example actually pull the certificate, or is the traffic simply sent over the port in an encrypted state, without a handshake between servers relative to the cert?
Is it mandatory that I IIS have a certificate as well for this to work? I should say that I am using this pattern: http://forums.asp.net/p/907421/1007517.aspx.
SSL isn't involved here.
What's serverPath look like? You probably are timing out on something - DNS perhaps. I'd start with a network trace.
When you use port 636, LDAP over SSL is used,
http://en.wikipedia.org/wiki/Ldap
If you use Microsoft Network Monitor or Wireshark to capture the packets, you may gain more insights on packet level.
In this case, CRL is necessary as it is enabled by default. But you can turn it off on machine or application level,
http://www.page-house.com/blog/2009/04/how-to-disable-crl-checking.html
I have developed a web service and host it on my server and I would like to know who is using this web service (site Url). I tryed to use "Request.UrlReferrer" but it is not returning any thing! any suggestions/Advices?
You can't get the URL of the caller of a web service as not all callers have canonical URL's. You can however get the IP Addresses assuming that they are not behind a proxy / nat. In which case you'd get the IP of the nat / proxy.
Assuming your using an ASMX web service you can this from:
HttpContext.Current.Request.UserHostAddress
Once you have the IP Address you can try and do a reverse lookup to get the host name. I would recommend storing the IP address then writting an offline process which goes and tries to determine who owns the IP. I'm sure there are some webservices out there to help with this.
You can use Request.Url property to get all the information about the requests to your web service.
The referrer is set by the client, and the client can not set it. That is why you see nothing. If the client's are servers, then the best you can do is to get the IP of the client connection and go to that IP. If a simple setup, with no virtual hosts, then that is the "web site" that is hitting your web service.
As Josh states, the HttpRequest object is the way to go, there are a few properties on there that might help:
UserHostName - Gets the DNS name of the remote client.
UserAgent - Gets the raw user agent string of the client browser.
UserHostAddress - Gets the IP host address of the remote client.
Which might give you a bit more information to play with.
I have an ASP.NET application that will host multiple tenants (Software-as-a-Service style). Each tenant will have their own domain name (www.mydomain.com, www.yourdomain.com) and their own SSL certificate.
Is there a way to host the application such that all of the tenants are on the same application instance?
I know you can have multiple IIS web sites pointing to the same shared location, but that won't work - it's not the same instance. That's different instances of the same application.
I also know you can use SSL host header mapping with wildcard certificates, but that won't work because all of the tenants would need to be subdomains of the same primary domain - yourdomain.commondomain.com, mydomain.commondomain.com. For the solution to be valid, everyone needs to have their own domain name, not be subdomains. (Ideally each tenant could opt to use an EV cert, too, and you can't have wildcard EV certs.)
The problem is that classic SSL requires the certificate to be presented before the web browser has indicated which host it wants to use. You can therefore only configure one certificate per IP/port combination.
There is an extension to TLS called Server Name Indication which allows the browser to indicate which logical server it wants to talk to. This feature is supported as of IIS 8.0 (Windows Server 2012).
Wildcards work because the certificate itself says that it is valid for all servers under that domain.
You constrained to only IIS - or could putting soft/hard proxies or content-switching hardware also be an option?
Thinking that you could terminate the SSL at a proxy or content-switch - then transform the request into your own internal url.
e.g. foo.com/x and bar.com/y get translated into myapp/x and myapp/y respectively under the hood - passing the original hostname in the request headers.