Thursday, October 19, 2017

Git: Setting Name/Email from the Command-Line


After logging into to git using your credentials, git knows  you are logged in but does not always know who you are with respect to your name and email. Adding this to  your global git settings is a matter of invoking git config --global as follows:

git config --global user.name "Jan David Narkiewicz"
git config --global user.email "jann@sofwarepronto.com"

Obviously, users should specify their own name and email address when  updating git's global configuration settings.



Monday, October 16, 2017

Windows 10: Logging out of the current Git account

I find myself working from multiple Git accounts while logged into the same Windows login. Normally I use Git exclusively from the command-line but when logging out of Git to insure I can login and receive a new login-prompt, I use Control Panel, specifically the dialog for managing Windows Credentials -- see path:
Control Panel | User Accounts | Credential Manager | Manage Windows Credentials

In order to access this functionality, display Control Panel:


Select User Accounts which displays the following:

Under Manager your credentials select Windows Credentials:


 Notice in the previous screenshot that there are git related credentials under heading, Generic Credentials. To the right of git:https://github.com click on expand button,


Clicking on this button reveals the following:


The Remove button removes the credential. Remove all git related credentials to be force git to prompt for a new user login.

Sunday, October 8, 2017

C#: Running Google OAuth 2.0 for Desktop Apps on Windows 7

This article demonstrates the code required to make Google OAuth 2.0  for Windows desktop applications work with Windows 7.

Google OAuth 2.0 means that an application can relying on Google's user credentials in order to support authentication. The users of an application can use their GMail address and corresponding password to login to a non-Google application. In order to implement OAuth 2.0 support, there are variety of steps that must be taken from an application registration process and a development standpoint.  Google has created extremely comprehensive documentation with regards to supporting this authentication protocol, "OAuth 2.0 for Mobile & Desktop Apps" and has also provided series of examples on github.com, https://github.com/googlesamples/oauth-apps-for-windows.git, that target a variety of Windows desktop configurations. The problem with the Windows desktop samples provided is that they fail on Windows 7.

The solution from example Windows console application from the aforementioned github.com, URI appears as follows in Visual Studio's Solution Explorer:



When this applications run on Windows 7 an exception is thrown and an "Access is denied" error message is displayed:


The specific line at which exception is thrown is line 78 in the following screenshot (the Start method of an instance of the HttpListener class):


The mechanism used to fix the Access Denied error is to "Reserves the specified URL for non-administrator users and accounts" (see "add urlacl") by means of the netsh command with the http add urlacl arguments. Basically this means, the user has permission to create an HttpListener instance and to listen on the URl by invoking HttpListener.Start. In invoking netsh to facilitate URL access is handled by the Process class's (see the System.Diagnostics namespace) Start method. An example of invoking netsh using Process.Start to allow a user to access a specific URL is show as follows:

public static void EnableAccessOnWindows7(string url)
{
    string domain = Environment.UserDomainName;
    string user = Environment.UserName;
    string commandArgs = 
             $"http add urlacl url={url} user={domain}\\{user}";
    ProcessStartInfo startInfo = 
             new ProcessStartInfo("netsh", commandArgs);

    startInfo.Verb = "runas";
    startInfo.CreateNoWindow = true;
    startInfo.WindowStyle = ProcessWindowStyle.Hidden;
    startInfo.UseShellExecute = true;
    Process.Start(startInfo).WaitForExit();
}

The EnableAccessOnWindows7 method is invoked by Google OAuth 2.0 Console Application sample at line 68 to allow the sample to run on Windows 7:


Given the changes made the sample now runs on Windows 7.

Source Code

Normally source code for these posts is made available through github.com. Google owns the sample reference and maintains a master copy in their own github.com repository: https://github.com/googlesamples/oauth-apps-for-windows.git. The code associated with the modifications required to allow the desktop samples to run on windows 7 are included in the body of this post.

Wednesday, September 13, 2017

Configuring Windows to use a PAC File or Proxy Server

This post demonstrates configuring Windows to make use of a PAC file and/or Proxy server. These settings apply to a given user rather then applying to an application that programmatically species a PAC file or proxy server. All .NET applications that adhere to standard programming principles will make sure of the PAC file and/or proxy server information specified for a given user.  As an example, the following rather mundane code will route the request to google.com through a proxy server if one has been configured for a given user on Windows:

class Program
{
  static void Main(string[] args)
  {
    using (WebClient webClient = new WebClient())
    {
      string str = webClient.DownloadString(
                     "http://www.google.com");

      Console.WriteLine(str);
    }
  }                           
}

Notice in the above sample there is no code whose purpose is to set up or configure a PAC file or proxy server. It all just works under the covers. The PAC file and/or proxy server can be set using “Auto proxy configuration settings for Internet Explorer.”

As an example of how a PAC File and Proxy can be set using “Auto proxy configuration settings for Internet Explorer” is as follows:

  1. Launch Internet Explorer
  2. Click on the gear icon in the upper right corner and select Internet options:


  1. Click on the Internet options menu item displays the Internet Options dialog. From the Internet Options dialog select the Connection tab (see below):


  1. On the Internet Options dialog, click on the LAN settings button which displays the Local Area Network (LAN) Settings dialog:


  1. The Local Area Network (LAN) Settings dialog is organized as follows:
    1. The group box at the top is entitled “Automatic configuration” and the purpose of this section is to assign a PAC File that can be used by the Windows (including .NET applications).
    2. The group box at the bottom is entitled, “Proxy server” and the purpose of this section is to assign a Proxy Server to be used by Windows (including .NET applications).
  2. To assign a PAC File that will be used by Windows applications configuration the Local Area Network (LAN) Settings dialog as follows:

  1. Note that in the screenshot above that
    1. The checkbox “Automatically detect settings” was checked so that applications will pickup the specific PAC File automatically.
    2. The checkbox “Use automatic configuration script” when checked enables a text box in which a PAC File (which is really a URL pointing to a file) can be specified.
  2. To assign a Proxy Server that will be used by Windows applications configuration the Local Area Network (LAN) Settings dialog as follows:

  1. Note that in the screenshot above that
    1. The checkbox “use a proxy server for your LAN” was checked so that applications will pickup the specific Proxy Server automatically.
    2. The text boxes below this check box allow the proxy server host and the port it listens on to be specified
    3. The checkbox “Bypass proxy server for local address” when checked enables a application to make calls against local host. Such calls are necessary, for example, when performing OAuth authentication against Google. A local browser (127.0.0.1) is used to retrieve the authentication code returned by Google.
Notice that there is no way to specify user credentials with regards to the proxy or proxies specified in the PAC file (top portion of the Local Area Network (LAN) Settings dialog). Also notice that there is no way to specify user credentials with regards to the proxy server specified in the lower portion of the Local Area Network (LAN) Settings dialog.  By default applications use the default login credentials to access a proxy server.











Sunday, July 23, 2017

Setting up Apache2 (a web server on which to host PAC files) on Ubuntu

In this posting the steps to setup Apache2 on Ubuntu are reviewed. The reason for needing a web server (Apache2) is to host a PAC file. A PAC file (proxy auto-config) is used to map a URL to a proxy (host/port). The contents are of the PAC file are javascript (a simple script that when invoked takes a URL and returns the string required to access the proxy). Applications access PAC files based on their URL so to develop an application that makes use of PAC files a web server is required.

Apache is a package so on the server run the following to update the package information:
sudo apt-get update

Running the previous commands displays the following:

Once the package information has been updated run the following command:
sudo apt-get install apache2

An example of the previous command's invocation is as follows (a small snippet from a great deal of output):


The status of Apache2 can be verified as follows:

With the previous installation and status check, Apache is not quite ready. The inbound port for apache has to be open.

A web server uses port 80 and on an Azure hosted Ubuntu virtual machine this port is not open. Recall the previous post that demonstrated how to open an inbound port for the Azure virtual machine, Opening an inbound port for an Ubuntu Virtual Machine on Azure. If HTTPS is to be used, open port 443.

Once setup, the next step in order to full support proxies will be to create the PAC file copy it to Apache's content folder.




Tuesday, July 18, 2017

OS/X Dock visible in full-screen VMWare Fusion

A great many developers using Macs run VMWare Fusion in full screen mode. At times (for no apparent reason) OS/X's dock remains visible even though VMWare Fusion is full screen mode.



The solution to this problem to open a terminal window in OS/X and execute the following command:

killall -KILL Dock

The Dock will be deleted and restarted using the above command.

Sunday, July 16, 2017

Windows: Testing if a remote port is open using Telnet

In a previous post, Opening an inbound port for an Ubuntu Virtual Machine on Azure, an inbound port was open on an Ubuntu virtual machine (port 21777) and on this host a service (tinyproxy) was installed that listens on this port via TCP/IP. Obviously, there should be a way to test that the port is actually open and if the underling service is actually listening. This can be accomplished using a telnet client on Windows. Previously it was shown how to insure the telnet client is installed on Windows (Making Telnet Client available on Windows).

Telnet is used from a console window and written as follows where telnet will establish a TCP/IP connection:

telnet <host|ip> <port>

An example of this as follows where the IP is an Ubuntu server and port 22 the port used by SSH:


When enter is is clicked on in the previous console window, the following is displayed:


Above it can be seen that the telnet connection accessed the SSH service on the Ubantu server. This means port 22 is open and SSH is listening on the port.

The exercise in testing ports relates to installing a tinyproxy proxy service on an Ubuntu service. The tinyproxy service is listening on port 21777 using TCP. To test the port port the following is entered in a Windows console window:


When the above command is invoked the following is displayed:


What appears to be blank screen actually means that telenet success accessed the tinyproxy service on port 21777.

Below is an example of telet being invoked on a port that is not open for the Ubuntu server:


Invoking the command above results in the following:


The screenshot above shows telnet waiting in vain for port 21778:


Eventually the attempted by telnet to connection to port 21778 will time out resulting in text such is displayed above.

So using telnet or bash (Testing if a remote port is open using BASH /dev/tcp/host/port) it has been shown how to determine if a port is open on  a remote server with a service listening on the port.