Automatic client redirection (similar to a captive portal)

I've installed the 1.1.3 build on a Raspberry Pi Zero W. It's working great!

One apparent "glitch" for my use case is that non-technical users may have trouble connecting to the PirateBox. My Windows PC allows me to connect but warns that there is no Internet. And then it sometimes redirects to [piratebox.lan] but other times I need to go to an [anything-that-redirects.lan] address in my browser to get there.

From my Android phone, I'm warned that there is no Internet connectivity and asked if it should remain connected. I have to say Yes and then manually go to an http address in the browser to get redirected to the appropriate content. Omitting the http:// or using an address that doesn't have a common TLD (such as [gfsgfjsls.fsdsd]) causes the browser to try an Internet search, which fails because it's trying to use https for that.

I think iOS devices may have a similar issue, but I don't have one to test with at the moment.

So, the one remaining thing I'm hoping for is a way to guide users to the web site. I'll use a paper sign, but I think that "captive portal" technology might be better?

Is there an easy way to enable a light weight captive portal, or a package I can install that works alongside the existing [piratebox.lan] server? (It is also acceptable to replace the lighttpd instance; I just need a way to serve static content.) I don't actually want users to authenticate or anything like that -- instead, I'd like a simple way to get them linked over to [piratebox.lan].

Hi,
ok, I start talking about that topic more like general, then I work on your points.

PirateBox is a complete offline network. Some devices will drop off this wifi, if they do not detect a internet connection*. So PirateBox implemented some fake answers, but as far we discovered it and were able to implement it.
* It seems that the drop-off behavior changed during the last year for iOS, but there are still issues with some android devices.

What we fake and what not:
iOS - We answer always "yes internet"
Android - We always answer yes internet, as the Android version follows the official Google approach
Windows phone - for older it works
Windows 10 (phone) - not yet available

The result of a correct answer is, that no browser pops up. That is intended, because especially on iOS the captive portal browser is very much limited, so it suddenly closes or does not work correctly. Upload does not work and other mobile OS do not work properly without the fake answer.

In addition, Piratebox does not react on HTTPS requests, which will result in a "connection failed/refused" message. This happens if you enter "google.com" into the browser, which now (in year 2017) always assumes "https ://google.com" and not "http ://google.com". So that request just fails.
If you enter something unknown or uncommon, http is assumed and it works.
On PirateBox 1.1.3 we do a redirect always back to the hostname, that the browser cache is not too much confused about the redirect.
HTTPS port is not enabled, because it would need a certificate.. yes we can auto-generate it, but today's browsers do "certificate pinning" and especially on pages like Facebook or Google you will get a BIG FAT ERROR message.. no, you can not redirect to piratebox.lan before doing a SSL handshake.

The common used captive portals have a lot downsides. My personal most hard critic point is, that devices which can' answer a captive portal page, will not work correctly. My custom implementation using nodogsplash also breaks the mesh feature.
Just yesterday, I pushed a customized version of a-sort-of- implementation of a captive portal to the development branch. It reacts only to these fake requests and does answer them with a redirect on a "howto page", after a while (after 5 requests you get a valid fake answer (lol)) or confirming the box is answering with correct replies. This was tested with iOS, but I still need some user feedback from Android and others. (Development images will be rebuild today).

I think that will explain alot and it seems I need to put it on piratebox.cc ..

best regards Matthias

Thank you for the explanation. It seems that as the web becomes safer from bad actors, it also becomes more difficult to run disconnected networks.

I am happy to hear that you are working on a simplified, minimal captive portal approach. I like the idea of it being a how-to page that can tell the visitor to go to a specific web page after they "authenticate" on the portal.

I was going to look into Nodogsplash, but my initial view of it was somewhat intimidating. My Pi Zero W is headless and has no Ethernet. I was amazed at how easy it was to set up PirateBox via the default Wi-Fi connection and SSH! You've done great work.

Thank you for the feedback about my captive portal idea.

Thank you very much. In fact, the smoothness of the wifi startup on RPi devices is not my success.. a member of the forum contributed a good idea for that (and reworked alot of the build process).

I am currently refreshing the OpenWrt version ... which is always sooo time consuming. phew.

If you are good at PHP, I am looking for someone who can rewrite the the shoutbox and the diskusage from python to PHP.

best regards
Matthias

You don't give yourself enough credit, Matthias.

I don't know PHP. I know a bit of Python, but at the beginner or intermediate level. Also, I'm not using Shoutbox, Diskusage, or Droopy. I wish you had C# tasks for me.