Setting Your Metric for Hyper-V Wireless Networking

Monday, June 10, 2019 by Nate Bross

I've been struggling to setup Hyper-V networking on a laptop for a while now. Until recently I was able to work around it, and not actually solve the problem.

Its well documented, that sharing a Wireless network card in Hyper-V wont work. Since Windows 10 1709, a nifty 'Default Switch' has been provided to help VMs connect to the network via NAT using the hosts default connection. I could only ever get this to work intermittently. Why? Metric.

I believe this has something to do with my specific setup, so I'll outline that too. I use my laptop in three primary modes. 

  1. Docked which has multiple DisplayPort, USB, 3.5mm, and Ethernet ports, but I use wireless networking
  2. Totally mobile, not connected to anything but power, obviously wireless.
  3. USB-C Dock with HDMI and USB, again wireless networking.

Eventually I came to notice that it worked when I was not docked. As a diagnostic step I disabled the unused Ethernet connection, and things started working. This told me there was some issue with determining which connection the VM should use.

I set the Metric on my Wireless connection to 1, on my Virtual Adapter (VPN) to 2, and my Wired Ethernet to 50. Things have been working great since. Go figure.

Adapter Settings => IPv4 Properties => Advanced => Uncheck Automatic metric, and specify a value.

 

Comprehensive Guide to Fixing the FileMaker Web View Control on Windows

Tuesday, May 14, 2019 by Nate Bross

Working with the FileMaker Web View control can be a challenge on windows. The FileMaker Web View control is essentially a shim that allows us to put the MSHTML Control on a FileMaker layout. Common wisdom is that this control is "essentially IE" while true, that is misleading. By default the control operates in IE5.5 mode!  There is a lot of historical information and decisions that brought us to those defaults. Fact is, it doesn't have to remain that way. I'm going to outline how to get the MSHTML Control up to IE11 mode.

There are a couple levers we can pull to nudge the control into supporting modern standards. The Document Mode and the Input Model.

Setting up "Document Mode"

There are several ways to set the document mode that the control uses, and this behaves much like the IE the full browser. It can be specified couple ways.

HTTP Header sent from the web server hosting the content loaded in the control.

This can be done many ways, depending on the server system in question. A simple way for a site hosted by IIS is to simply add this to web.config:

<system.webServer>
<httpProtocol>
<customHeaders>
<clear />
<add name="X-UA-Compatible" value="IE=Edge" />
</customHeaders>
</httpProtocol>
</system.webServer>

Meta tag in the body of the document rendered

Lots of examples of doing this method. Advantage to this method is that it works with a data url.

Registry setting on the computer running FileMaker Pro

Each method has benefits and drawbacks, and the later versions of FileMaker set the registry setting during install. FileMaker v16 and v17 both do. Other versions YMMV. It looks like this:

feature browser emuluation registry screen shot

Configuring the Input Model

The input model is the flag that toggles some more modern javascript apis, such as Pointer Events, among others. This can only be controlled via a registry setting on the computer running FileMaker Pro.

To DISABLE Legacy Input Mode (which is enabled unless you do this for any MSHTML Control) you must create the following registry key:

HKEY_CURRENT_USER (HKLM requires different keys based on bitness of FMPA version)
SOFTWARE
Microsoft
Internet Explorer
Main
FeatureControl
FEATURE_NINPUT_LEGACYMODE
FileMaker Pro Advanced.exe = (DWORD) 00000000

The zero value tell the operating system that when "FileMaker Pro Advanced.exe" (adjust accordingly if you're not using advanced) requests an MSHTML Control, it should disable the Legacy Input mode which is intended to support old legacy enterprise systems built for IE5.5 or IE6.

This is what it looks like prior to creating any entries:

empty registry section for legacy mode

Once you've pulled both levers, modern websites and controls will work much better while embedded inside your FileMaker solution. We're still working with IE11, so rendering issues will still present themselves. Your site must account for this, but at least more modern programming APIs will be available.

Debugging Javascript in a FileMaker Web View Control

Tuesday, April 16, 2019 by Nate Bross

Using built in FileMaker tooling, there is no way to see output from console.log, or other diagnostic tools when deploying some web content inside a web view control. I have found a way to do it using some freely available tools.

Here's a little demonstration of how it works:

console.log shows in visual studio

Using Visual Studio 2017 Community edition (download), it is possible to get access to this information. The process is simple once you know the steps.

Step 1: Open your solution to a layout with your web view control.

Step 2: Fire up Visual Studio, and use the Debug => Attach To Process menu:

Attach To Process Menu Item

Step 3: Select debugging type as "Scripting"

Set-Scripting-As-Debug-Attach-To

Step 4: Attach to the "FileMaker Pro Advanced.exe" process.

Step 5: Use Debug => Window => Script Console.

Debug-Show-Window-Javascript-Console

Once attached, you can view the console output and even script source and hit break points and step through code line by line. Basically anything you can do in the Internet Explorer 11 Developer Tools, you can do through Visual Studio attached to the web view control

It seems to work best if the layout has only one web view control. I've run into an error that Visual Studio was unable to attach to the process, and restarting FileMaker has corrected that.

For reasons I have not yet been able to understand, once you enter layout mode, you cannot attach for debugging to that instance of FileMaker anymore. You have to close FileMaker and start over. If you know why this is, or a way around it please reach out to me. I'd love to update this post with that information.

For reference, the tests above used a single file with a simple layout with a web viewer pointed at a field with this value:

data:text/html,<!DOCTYPE html><head><meta http-equiv="X-UA-Compatible" content="IE=Edge" /></head><body><button id="click">Logs</button><script>document.getElementById('click').addEventListener('click', function() { console.log('logged from click'); }, false)</script></body>

How to provide non-webpack'd configuration (easy to edit post-build/deploy) to a webpack'd single page application

Tuesday, February 5, 2019 by Nate Bross

SPAs, or single page applications, are all the rage these days. They have their merits, and they are beneficial for many scenarios. One issue that has plagued me repeatedly when working on SPAs is trying to define environment specific variables that are NOT KNOWN at build time. WebPack is great, and scary, and confusing all at the same time, but it packages everything up at once. If you don't know the value at build time, you're out of luck.

While there are dozens of ways to handle this situation, some including separate build and release pipelines with tokens, I opted for a more low tech solution. Let me set the stage before I continue, as I think it helps paint the picture around why I like this solution. My app connects to some web services, and the uri of said services will be different for each deployment. Its important to note, that my SPA and web services are hosted on different domains and setup with CORS configuration. I can't simply use relative paths.

I created a simple config.js file and included it in the head section of my index.html (the entry point for my SPA). It looks like this:

window.api_root_url = "https://runtime-api.example.com";
window.client_id = "my-client-id-for-open-id-connect";

In my SPA code (I'm using typescript) I created a simple globals.ts file which wraps these into type safe constants.

export const apiRootUrl: string = (window as any).api_root_url;
export const clientId: string = (window as any).client_id;

and then whenever I need to reference my api endpoint or my client id I can simply import and use:

import * as globals from '@/globals';
// later on...
console.log(globals.apiRootUrl);

This works well, and provides a single file to edit on the deployed solution. It makes it easy to configure via ftp, ssh, rdp, etc.

When a Difference In Your Environment Make a Difference

Wednesday, January 9, 2019 by Nate Bross

I'm using IdentityServer4 for a couple projects. Its great, and might warrant a post of its own; however, one thing I've been struggling with is loading the jwt signing certificates. I've been using the powershell cmdlet New-SelfSignedCertificate to generate the pfx files and it works great on my local computer.

Running this on a web server has caused some grief, but lead to my learning a bit more about how these things actually work.

This is the final code that works, but I'll walk through how I got to it.

​new X509Certificate2(keyFilePath, keyFilePassword, X509KeyStorageFlags.MachineKeySet | X509KeyStorageFlags.EphemeralKeySet)​

The first thing is that the certificate file itself can have indicators stating whether to load to User store or Machine store; so I've used MachineKeySet to ensure we override that.

Additionally I'm also specifying EphemeralKeySet, which indicates the private keys should not be persisted anywhere. This is the key part that allows everything to work when running as ApplicationPoolIdentity on a server without administrative privileges.

Without passing the additional Storage Flags, the system uses whats in the certificate file/data and that works locally since I have a user profile and/or administrative rights. By default, IIS does NOT load the user profile which means no environment variables or user certificate store. In order to use MachineKeySet you need administrative privileges (something your web facing accounts should not have) so that's where Ephemeral comes in to play. Nothing is persisted so the admin rights are not needed. There are some incompatibilities with this approach; noted in the sources below, but for jwt signing it works.

For reference and searches, here are the errors I got/overcame.

Using default constructor without flags:

Internal.Cryptography.CryptoThrowHelper+WindowsCryptographicException: The system cannot find the file specified

Specifying only MachineKeySet, while running as ApplicationPoolIdentity:

Internal.Cryptography.CryptoThrowHelper+WindowsCryptographicException: Access denied

Relevant sources:

 View More Posts

Top Posts

About Me


Proud Contributor 

profile for Nate on Stack Exchange, a network of free, community-driven Q&A sites


Thoughts, opinions, and ideas shared here are my own. All content © Nate Bross 2019.