/dev/urandom

Using Cloudflare workers to shorten G-suite urls

Surya Teja Palavalasa -

I have been using G-suite to host custom email domain, I tinkered with the idea of hosting it on my own, but I wasn't confident enough to use it as my primary email without sacrificing availability or cost-effectiveness.

The Issue:

Many companies use G-suite to host their mail, and toggling between personal and work email is cumbersome. Google tries to alleviate the problem by providing a service to shorten various app URLs, such as mail, from mail.google.com/a/<domain_name> to mail.<domain_name>.com. Companies make use of this to provide an intuitive URL for their mail services.

For example:

$ dig mail.spotify.com +noall +answer
mail.spotify.com.	232	IN	CNAME	ghs.google.com.
ghs.google.com.		232	IN	A	216.58.203.211

Spotify CNAME's the intuitive domain mail.spotify.com to a google hosted service which redirects it to mail.google.com/a/<domain_name>

$ curl  mail.spotify.com 
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="https://mail.google.com/a/spotify.com">here</A>.
</BODY></HTML>

The issue with this approach is mail.<domain_name>.com cannot have strict HTTPS enabled as google does not own a valid https certificate for your domain

$ curl  -v https://mail.spotify.com 
*   Trying 172.217.160.211:443...
* TCP_NODELAY set
* Connected to mail.spotify.com (172.217.160.211) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to mail.spotify.com:443 
* Closing connection 0
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to mail.spotify.com:443

Possible Solutions:

  1. You could proxy requests to mail.<domain_name>.com to the origin(which would host your TLS creds) that generates the redirect.
  2. You could use Cloudflare page rules to generate redirects.
  3. Use Cloudflare Workers to run a js at the edge and issue a corresponding redirect.

I choose the 3rd option to write a javascript code that would run on Cloudflare edge achieving the least latency possible.

async function handleRequest(request) {
  let requestURL = new URL(request.url)
  let path = requestURL.pathname.split('/')[1]
  let location = redirectMap.get(path)
  if (location) {
    return Response.redirect(location, 301)
  } else {
    return Response.redirect("https://suryateja.dev/img/404-southpark.webp", 302)
  }
  // If in map, return the original request
  return fetch(request)
}
addEventListener('fetch', async event => {
  event.respondWith(handleRequest(event.request))
})
const redirectMap = new Map([
  ['mail', 'https://mail.google.com/a/suryateja.dev'],
  ['drive', 'https://drive.google.com/a/suryateja.dev'],
  ['calendar', 'https://www.google.com/calendar/hosted/suryateja.dev'],
])

I've added a new subdomain ("apps") and null routed it to 1.2.3.4  in the DNS. The worker running on the subdomain would redirect to different G-Suite apps using the path.

PS: Even-though URL shortening is convenient to have, it's not a deal-breaker. My primary goal was to try Cloudflare Workers and work on a use case. Cloudflare workers provide a new approach towards edge computing by running a sandboxed code on the V8 javascript engine. It supports web-assembly that lets you write complex code in your favorite language. I am thrilled to watch the growth of this new architecture.