Recently, I am working on improving the Zoraxy (my open source reverse proxy server written in Golang). As this is not a post about reverse proxy but UX, I am gonna sum up this project in one sentence: Zoraxy is a reverse proxy server that uses UX first design.
And one of the most challenging part I recently encounter is designing a UI for the header rewrite rule sets.
What is a header rewrite rule?
A header rewrite rule set is a few lines of header key-value that is gonna be injected into the HTTP request header when the proxy is processing the request. The rewrite can happens in two directions. One is when the request is proxying from downstream to upstream (aka from client like user's browsers to origin server like web server), another one is from upstream to downstream. Not to mention each direction there will be two operations, either you can add a new header to the request header, or delete a header from the current request.
Design for beginners vs professionals
For those who have networking background, it is a really simple thing to understand. However, Zoraxy is aiming for users who have little to no networking background, how to express the correct meaning to user gives me some great headache in designing the UI for this function.
UI for adding custom headers
Eventually, I come up with a solution. So first I created a web form that try to avoid the upstream and downstream technical terms and favor for a more easily understandable diagrams. Next, adding the next step of the operations as a new sets of buttons below the direction choosing buttons.
Then now, we have a very clear and easy to operate web form for creating and editing custom headers. Next, how can we list the current existing custom headers?
UI for Listing Current Custom Headers
To list the custom headers with direction indication, we can reuse the cognitive awareness that the user learnt while creating the custom header. So in the table of custom headers, I uses the same color and direction arrows to indicate the header add / remove directions. I also pick the same add and remove icon as the operations buttons. So now, we can easily get a sense on how and when the header is being rewritten.
And well, sometime user forgets their experience in creating custom headers. They might be setting this up last year and now revising the table and forgotten what those arrows means. So I added two lines of instruction at the bottom of the table. For the "add" and "remove" icon, I think that is common sense enough that I don't need to explain them so I didn't left a remarks for them.
Permission-Policy
Permission-Policy is a HTTP header that defines what policy / sensors that your website can access. It is a terribly long header that looks something like this
Permissions-Policy: accelerometer=*, ambient-light-sensor=(self),
autoplay=*, battery=(), camera=*, cross-origin-isolated=(),
display-capture=*, document-domain=(self), encrypted-media=*,
execution-while-not-rendered=*, fullscreen=(self), geolocation=*,
gyroscope=(), keyboard-map=(self), magnetometer=*, microphone=*,
midi=*, navigation-override=*, payment=*, picture-in-picture=(),
publickey-credentials-get=*, screen-wake-lock=*,
sync-xhr=(self), usb=*, web-share=*, xr-spatial-tracking=*,
clipboard-read=*, clipboard-write=(self), gamepad=(),
speaker-selection=(self), conversion-measurement=*,
focus-without-user-activation=*, hid=(), idle-detection=*,
interest-cohort=*, serial=(), sync-script=(self),
trust-token-redemption=*, unload=(self), window-placement=*,
vertical-scroll=*
If I am developing for professionals, I could have just left a text-area and call it a day. However, Zoraxy is design for beginner and if I leave a text-area in place, people are gonna fill in some weird things and open bug issues claiming Zoraxy is not working and buggy. That is why I designed a web form for it again.
At the bottom of the list, there are a separately color section for experimental policies. This can help notify the user that these might not be supported by all browsers.
And this is probably the longest web form I have developed for this project. But at least this details here can make sure no one fill in invalid stuffs into the Permission-Policy header field (I hope)
Anyway, this project really challenge my UX design experience. I guess nowadays most devs will just use framework and make the UI looks good, but UI looking good is not the same as good UX. Sometime attention to details like this might helps a lot in allow user to stick with your software and willing to contribute.
Lastly, here is the git repo if you are looking for an easy to use reverse proxy server and you are interested to give it a try.
Zoraxy
A general purpose HTTP reverse proxy and forwarding tool. Now written in Go!
Features
- Simple to use interface with detail in-system instructions
- Reverse Proxy (HTTP/2)
- Virtual Directory
- WebSocket Proxy (automatic, no set-up needed)
- Basic Auth
- Alias Hostnames
- Custom Headers
- Redirection Rules
- TLS / SSL setup and deploy
- ACME features like auto-renew to serve your sites in https
- SNI support (and SAN certs)
- DNS Challenge for Let's Encrypt and these DNS providers
- Blacklist / Whitelist by country or IP address (single IP, CIDR or wildcard for beginners)
- Global Area Network Controller Web UI (ZeroTier not included)
- TCP Tunneling / Proxy
- Integrated Up-time Monitor
- Web-SSH Terminal
- Utilities
- CIDR IP converters
- mDNS Scanner
- IP Scanner
- Others
- Basic single-admin management mode
- External permission management system for easy system integration
- SMTP config for password reset
Downloads
Windows /Linux (amd64) /Linux (arm64)
For other systems or architectures, please see Release
Getting Started
…That is all for today. Have a nice day :)
Top comments (1)
Cool project!