Monday, November 6, 2017

C#: Sending mail SmtpClient using of app.config/web.config

Scanning the web I found a large number of examples demonstrating the use of SmtpClient where the email host, port, username, password, etc. was stored in app.config or web.config. In most cases the developer put a few settings in the configuration file and then hard code the remainder of the settings in their C# code. This is frankly a bunch of malarkey.

This is all the code needed to send email (not their is not hard code information about the SMTP server or any of its properties):

// Add an assembly reference to System.Net
using System.Net.Mail;

namespace MailSettingsApplication
{
  public class Mail
  {
    public void Send(
                  string recipient, 
                  string subject, 
                  string message)
    {
      var mail = new MailMessage()
      {
        Subject = subject,
        Body = message,
      };


      foreach (var recipient in recipients.Split(','))
      {
        mail.To.Add(recipient);
      }


      var client = new SmtpClient();

      client.Send(mail);
    }
  }
}

The C# code above has not hard coded knowledge of the SmtpClient or the from address used in MailMessage. This fallows the Sergeant Schultz design patter, "I know nothing."

Below are the required settings (app.config or web.config) to send email via outlook.com for example if you signed up for email using premium.outlook.com:

<system.net>
  <mailSettings>
    <smtp from="sender email here" 
          deliveryMethod="Network">
      <network 
        host = "smtp-mail.outlook.com" 
        port = "587"
        enableSsl ="true"
        userName="put username here" 
        password="put password here" />
    </smtp>
  </mailSettings>
</system.net>  

if you are not using outlook.com email then the settings (host, port, enableSsl) can be configured accordingly. 

The code for this blog can be found at https://github.com/softwarepronto/Blog under the MailSettingsMaster folder.

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.

Saturday, July 15, 2017

Testing if a remote port is open using BASH /dev/tcp/host/port

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 by BASH where a host/ip and port can be accessed using either of the following:

/dev/tcp/host/port
/dev/udp/host/port

The version to use depends on the type of connection to be opened to the port, tcp or udp. SSH (port 22) was used to access the Ubuntu virtual machine (IP address 52.183.120.51). From a remote machine's BASH shell (e.g. a Macbook Pro's Terminal) the following can be entered:

cat < /dev/tcp/52.183.120.51/22

As we can see from the screen shot port 22 is open on the host because there was a response ("SSH-2.0-OpenSSH_7.4p1 Ubuntu-10") when port 22 was opened:

Not every protocol is so obvious when connected to via TCP. Connecting to port 21777 (which is open for the host):

The connection above was success because it does not time out. Clearly the proxy is connected but does not send any kind of a reply on the initial TCP connection.

Connecting to a port that is not open such as 21778 results in the following (a time out):


The time out is not returned immediately but it does indicate the port is not open or that no service is listening to 21778 on TCP.




Saturday, July 8, 2017

Making Telnet Client available on Windows

Telnet is a handy utility that allows a TCP/IP connection to be made to a host/port. Unlike ping or tracert which simply detect if a hosts exists, telnet allows a connection to be opened to a specific port. This is handy in verifying that there is no firewall blocking an application running on a remote server (e.g. a proxy server -- Setting up a proxy server with TinyProxy on Ubuntu).

Telnet is a feature of Windows operating systems (the good news). The bad news is that it is not installed as part of a standard windows installation. This posting demonstrates how to add the Telnet Client feature of a Windows host.

The first step in add Telnet to a Windows host is to display control panel. To find control panel search on "Control Panel" from the desktop:


Click on the "Control Panel" above which displays the following:


To add a Telnet Client to Windows click on "Uninstall a program" (lower left corder of Control Panel above). If this seem counter intuitive remember that to shutdown previous versions of Windows you had to click on the Start button.

Click on "Uninstall a program" displays the following, the "Programs and Features" screen:


The upper left corner of the the "Programs and Features" screen contains a link entitled, "Turn Windows features on and off." Click on this link:


Clicking on the "Turn Windows features on and off" link displays the "Windows Features" dialog shown below:



Scrolling down the "Windows Features" screen will eventually display the "Telnet Client" checkbox. If this box is unchecked then the Telnet Client is not installed. To install the Telnet Client (when it is not currently installed) click on the corresponding checkbox (see below):


With the the "Telnet Client" checkbox checked, click on "OK" to install the feature. Clicking on "OK" displays the following:


The screen above is displayed while the "Telnet Client" feature is being installed. Once the screen above completes, the screen below is displayed:

The previous screen indicates that the "Telnet Client" features is insallted.

Tuesday, July 4, 2017

Linux, Unix and OS/X determining what shell is running

When running a terminal window it is possible to determine the current shell by running the following from the command-line:
echo $SHELL

An example of invoking this from an OS/X terminal window is as follows:


As echo $SHELL demonstrates above, the current shell is BASH.

The title bar of the OS/X terminal actually show the same information revealed by echo $SHELL, namely bash:


Monday, July 3, 2017

Setting up a proxy server with TinyProxy on Ubuntu

Introduction

This article demonstrates how to setup a TinyProxy proxy server on Ubuntu. The purposes of this proxy instance is to test client code targeting accessing web service via proxies and reading PAC file. The steps we took to get get to get to this point (the TinyProxy installer) are as follows (previous blog postings):

Setup and Configuration

1) To install, access the server on which tinyproxy is to be installed via ssh.
2) Execute the following command on the Ubuntu server via the terminal window:

sudo apt-get install tinyproxy

During install the terminal will generate output such as:



3) By invoking the following from the terminal we can determine current status of the newly installed tinyproxy:

service tinyproxy status

Invoking the previous command generates output such as the following:


From the previous screen we can see that the tinyproxy service is "active {running}" and is running as PID 71258.

4) To exit the status information simply type:
q

5) We need to change the configuration which is stored in a simple text file. In order to update the configuration file, the tinyproxy service must be stopped by invoking:

service tinyproxy stop

The output generated by this command is as follows:


6) To modify the configuration file associated with tinyprox, navigate to to /var/tiny/proxy

The ls invoked in the /etc/tinyproxy directory shows the configuration file for the service, tinyproxy.config.

7) Open tinyproxy.conf using vim (or editor of your choice) prefixed by sudo (only an administrator can edit the configuration file):
sudo vim tinyproxy.conf

The default contents of the the tinyproxy.cong file is as follows displayed in vim:


Notice above that the port for tinyproxy is set by default to 8888. Recall that the port we opened to access the Ubuntu server was 21777.

8) Delete the 8888 after the Port keyword and replace with a value of 21777:


9) Keep tinyproxy.config open in the editor because we need to modify the permission of our proxy server to allow any host to access tinyproxy.
10) Navigate down the configuration file util the "authorization controls" section has been reached.

Notice in the configuration file tinyproxy, tinyproxy.conf, that access is allowed to local host (IP address 127.0.0.1):



Place a # in front of the "Allow 127.0.0.1" line.:

There are now no explicit hosts permitted to access the tinyproxy instance. This means "allow access sne". This includes protocols HTTP and HTTPS.

12) Save the configuration file, tinyproxy.conf.
13) From the terminal invoke the following command to restart the tinyproxy service:
service start tinyproxy

The output generated by invoking this command is as follows:



Notice above that the user (administrator) credentials were required to be entered before the tinyproxy service started.

Verify Proxy is working using Extension Proxy SwitchyOmega

On a Windows system, the proxy settings can be se specified under Internet Explorer options. Using Chrome in conjunction with the Proxy SwitchyOmega allows extremely extensive proxy management.

To find the exertion for Chrome simply look up Proxy SwiticyOmega in any search engine. On google, the search term leads to the following screen:


The upper right corner of the web page contains a rather appropriate button:

Clicking on the "ADD TO CHROME" button disdfsplays the following:


From the previous dialog click on "Add extension":


When the Proxy SwitchyOmega extension is installed a series of tutorial screens are displayed (meaning you click on Next a lot). To break out of the tutorial wizard click on the X at the top right of the dialog.

Below notice that the extensions bar is displayed. The extension to the far right, marked by an icon that is a circle, is Proxy SwitchyOmega. Clicking on the circle icon displays the following:


At the bottom of the Proxy SwitchyOmega menu displayed above is the the Options menu item. Selecting on the Options menu items displays the following:

The previous screen allows the options to be managed for a proxy named, "proxy." To see more options selected "Show Advanced" which displays the following; 


The IP address for the new installed tinyproxy service is 52.191.142.196. Using the advanced options below the server (52.191.142.196) and port (21777) can be assigned to both the HTTP and HTTPS protocols:


On the lower left is in the "Apply changes" option:



Click on "Apply changes" means the Tinyproxy proxy, is ready to us. Clicking on the extension icon the proxy options menu can be displayed for TwitchyOmega:



The menu items above includes "proxy." Recall that the configuration setup to point the tinyproxy proxy was named "proxy." By selecting the proxy named "proxy" TwitchyOmega will point all Chrome traffic for HTTP and HTTPS at the proxy server just configured. 

Why not squid?

In addition to tinyproxy, the squid proxy, was researched as a potential proxy to setup. The proxy installed was not for a production environment. The proxy was to be used for development against HTTPS-based REST services. The reason tinyproxy was selected over squid, because tinyproxy was simpler to configure.