We just rolled out a new version of the Forward client, with a new feature that we’re pretty excited about: Forwardfiles.
When you’re using Forward with several projects, it can become tedious remembering which command-line options to use for each project. A Forwardfile lets you set options within a flatfile in the project itself. You can even track it in version control if you want (but be careful not to track authentication credentials).
Most of the options that you would specify via command line switches are supported, and map one-to-one to the Forwardfile. Also it’s just a YAML file, so you don’t need to learn any funky new syntax.
A few examples:
# Set the port to forward
port: 3000
# Set the host/vhost to forward
host: example.dev
# Set a static subdomain prefix to use
# (e.g. myapp-yourcompany.fwd.wf)
subdomain_prefix: myapp
# Set a CNAME to use
cname: foo.example.com
# Set a username and password
username: foo
password: bar
# Disable auth on this tunnel (useful if you have
# “require authentication" enabled in your preferences)
no_auth: true
So how do you use them? First update to the latest version of the Forward gem. Then just create a Forwardfile at the top level of your project and specify the options you want to set as shown above. Now cd into your project directory, and run forward. Depending on how many options you’ve set in your Forwardfile, you may not have to pass any option to the forward command at all.
We use Forward a lot, and know that sometimes it gets a little crazy when you’re constantly jumping between multiple projects. We think Forwardfiles are a good solution to the problem and we hope you find them useful.
Last week, we rolled out a change to the Forward servers that changed the way a few of the request headers were passed to local servers. Today, we’ve rolled out another one.
Originally, when a request to a Forward URL got to the local dev server, the Host header would be the Forward hostname, e.g. example.fwd.wf. This worked great for most people, but created an issue for our customers who use Pow, MAMP PRO, or other virtual host-based setups. To solve this, we made it so that if you Forward a virtual host, the Host header is set to your virtual hostname (e.g. example.dev), and we added the X-Forwarded-Host header, set to the Forward hostname (e.g. example.fwd.wf).
Later, we discovered another issue when Forwarding a WordPress site that’s running on regular MAMP. Our WordPress plugin looks at the X-Forwarded-Host header to fix the URLs in a Forwarded WordPress site, but we were only setting that header when Forwarding a virtual host. We decided that since Forward is a lot like a proxy, we might as well treat the request headers like one. So last week, we changed it so that the Host header would always be the name of the host being Forwarded, e.g. example.dev, or localhost, and the X-Forwarded-Host would always be the Forward hostname, e.g. example.fwd.wf.
But soon after we deployed that change, we started getting support emails and tweets about it. Turns out, lots of frameworks and dev servers rely on the Host header to do redirects, dynamically construct URLs, and do many other things.
In almost all of these cases, it’s possible to configure things to work fine, but that’s a lot of hassle for a lot of our customers. And it’s not in the spirit of Forward. So we decided to make one more change.
As of today, when you Forward a site using just the port (i.e. forward 3000), both the Host and the X-Forwarded-Host will be the Forward hostname (e.g. example.fwd.wf). And when you Forward a site using a virtual host (i.e. forward example.dev), the Host header will be your virtual host name, and X-Forwarded-Host will be the Forward hostname.
We think this will work for the vast majority of users, without having to do any special configuration on their part.
Let us know if you have any issues!
— The Forward Team
We’ve just launched support for using wildcard subdomains with your Forward URLs.
Now, for example, if your Forward URL is example.fwd.wf, requests for *.example.fwd.wf will be routed like you would expect. It works all the way down too: foo.example.fwd.wf, foo.bar.example.fwd.wf, and so on all work fine.
This also means that Pow users can now Forward all of their Pow apps with one command: forward dev. If your Forward URL is somecompany.fwd.wf, and you have a Pow app running at someapp.dev, you’ll be able to view it at someapp.somecompany.fwd.wf. NOTE: this will expose all of your Pow apps via the same Forward tunnel, which is probably not a good idea. We’d recommend Forwarding your Pow apps individually, like so: forward someapp.dev.
Let us know if you have any trouble.
—The Forward Team
Forward launched with support for password-protection. Each time you started a Forward, you could use the --auth option to set a username and password that would be required to open the Forward URL in a web browser. This worked great for occasionally password-protecting your Forwards, but could become tedious if you did it everyday.
So, we’ve added a new feature to make it more convenient for our customers who use password protection frequently. If you log in to forwardhq.com and click Preferences, you’ll find a new option to “automatically password-protect my Forwards”. With it enabled, you can leave off the --auth option when you start a Forward, and it’ll automatically use the username and password that you’ve set in Preferences.
If you’d like one of your Forwards to have a different username and password, you can still use the --auth option, and your Forward will use the username and password you provide instead of the default. And if you’ve set a default, but still want to create some non-password-protected Forwards, just use the --no-auth option when starting one.
Finally, many of our Business and Small Business customers work on secret projects for their clients. In those cases, it could be a big issue if a developer were to forget to password-protect their Forward and it leaked to the public. In order to prevent this, Business and Small Business customers will find a second option in Preferences to “require all Forwards to be password-protected”. Enabling this will make it so that all Forwards will require a username and password (either the default, or set with the --auth option) to view them.
After we sent out the first month’s email invoices, we got some requests for “real” invoices, particularly from our European customers.
Well, today we’ve launched real invoices. We’ll still be sending the same billing emails, but we’ve added some new stuff to the Billing section of your account on forwardhq.com. Now you can view a full version of each invoice, as well as all of your past invoices.
Also as a part of the new invoice feature, we’ve added a company name field for all accounts. For new customers: the field has been added to the sign up form. For existing customers: you should go set yours in the Account section on forwardhq.com before your next billing cycle. The account email address will be used as the the company name until you change it.
Finally, we’ve also added an “invoice notes” field under Billing, where you can add other information that will appear on your invoices beneath your company name, e.g. your address, VAT number, etc.
We hope you find the new invoices useful!
When we launched, all Forward URLs had a two-part subdomain: the first part being random characters, and the second part being your company’s suffix (e.g. fq3o-yourcompany.fwd.wf).
This is different from how subdomains behaved when using Showoff (Forward’s predecessor). With Showoff, an unlimited plan allowed you to choose a subdomain (e.g. yourcompany.showoff.io). And whenever you started a Showoff tunnel, you got that same subdomain every time, without having to pass in any extra parameters.
While building Forward, we switched to the two-part subdomains so that all users in a Business or Small business account could share a company name suffix. Initially, we decided to make Solo accounts also work this way so that everything would be consistent. However, this meant that for Solo account users, there was no way to get a simple subdomain like you could get with Showoff.
Well, our customers have spoken (enough of you to make us rethink our decision), and today we rolled out a change to Forward that makes Solo accounts work the way Showoff used to: when a Solo account user starts Forward, they’ll get the simple subdomain (e.g. yourcompany.showoff.io) by default—no random prefix, and no need to specify a custom prefix.
This change does not apply Business and Small Business accounts. These account types have multiple people using them at once, so it could become a nightmare for people trying to “claim” the simple subdomain, or trying to figure out who is using it at any given moment. We’re considering a few ways to handle this situation in the future, but for now we’ve intentionally omitted this feature in the interest of avoiding all the headaches.
Since the initial launch, we’ve received lots of helpful feedback and feature requests for Showoff (Forward’s predecessor) on twitter, via email, and especially through UserVoice.
Here’s a selection of major customer-requested features that we’ve included in Forward:
This is a big one. Forward lets you have a single business account with multiple users, so now everyone in your company can use Forward without having each person billed individually. Besides simplifying billing, this also lets everyone in the company create Forward URLs that are suffixed with the company’s Forward subdomain.
Now, whenever you start Forward, you have the option to enter a custom subdomain for your Forward. A non-random Forward URL helps prevent confusion when you’re juggling a few of them at a time. It’s also nice to be able to give your Forwards descriptive names, so people know what they’re clicking when they get a Forward URL from you.
When you give someone a Forward URL, normally they’ll be able to access it until you stop the Forward. But sometimes you need to shut down your computer, or close your laptop and carry it somewhere.
In these cases, when your computer isn’t connected to the internet, people who visit your Forward URL would see an error message saying your Forward wasn’t found. Previously, if someone tried to visit one of Forward URLs they’d see a generic error message. Now, you can supply your own (branded) HTML error page that tells visitors that your Forward is temporarily offline.
We’re always looking for ways to improve Forward, and we’d love to hear your suggestions. Let us know @forwardhq on Twitter.
