Previously a remote FAS could not use https protocol without generating
browser security errors or warnings so NDS enforced use of http.
A new FAS level, fas_secure_enabled = 3 is introduced here.
Level 3 is the same as level 2 except the use of https protocol is
enforced for FAS. In addition, the "authmon" daemon is loaded.
This daemon allows the external FAS, after client verification is complete,
to effectively traverse inbound firewalls and address translation to
achieve NDS authentication without generating browser security warnings.
or errors.
A fully functional https fas script is provided (fas-aes-https.php).
Signed-off-by: Rob White <rob@blue-wave.net>
This is a fix to allow "+" and "&" characters in user data passed to MHD in get requests.
Reported in issue #476, this effected PreAuth and Binauth.
"+" and "&" characters can now be used in form data, eg passwords etc.
Signed-off-by: Rob White <rob@blue-wave.net>
When option fas_secure_enabled '2' is set, get the client interface connections.
The client interface connections string is of the form:
[localif] [remotemeshnodemac] [localmeshif]
This is added to the query string as "clientif".
[remotemeshnodemac] and [localmeshif] will be null if the client is connected
to a local interface or 802.11s mesh networking is not active.
This can be used to change the response of the FAS captive portal login page,
depending on the interface the client is connected to.
Connections to local wireless interfaces and
remote 802.11s mesh node connections are detected.
Signed-off-by: Rob White <rob@blue-wave.net>
Allows simple switch between templated splash page and preauth login script.
Disabled:
option login_option_enabled '0'
use config options for FAS if set, or Templated Splash
Enabled:
option login_option_enabled '1'
use preauth login script providing username/email login with access log
Signed-off-by: Rob White <rob@blue-wave.net>
Simple configuration of fas running on remote shared hosting server.
Encrypt the query string sent to remote FAS.
Documentation Updates.
Bumping to v4.0.0
Signed-off-by: Rob White <rob@blue-wave.net>
With apologies for my previous insufficient contribution - the source tarball now (as originally intended) extracts into a directory with the name of the package.
Created cleaned (no remnants from previous builds, no .gitignore, no .git or dist folder) Debian source directory to prepare for upload to distribution.
Parsed VERSION from debian/changelog and have it as part of the Debian source tarball.
The stripping of binaries also removes debug information that comes handy for interpreting a core dump. Linux distributions have means to separate that information into separate files, then shipping in a separate -dbg package.
LibHTTPD doesn't support multi-threading at all. Some static variables,
for example `buf` in `httpdReadRequest`, is shared by all threads.
These cause a lot of unexpected behaviors and sgefaults.
However there are also some patches trying to solve it:
http://dev.wifidog.org/ticket/471 .
Those patches reduce the chance that cause NoDogSplash to crash, but
the bug still exists.
There are two ways to solve it. One is to remove the `static` modifier and
to bring more overhead to each request. Another solution is to not use
threads at all.
I prefer the later one. Since all requests can be handled very quickly,
I believe that won't increase the response time even if a lot of users
try to access it at the same time.
For the newer version of GCC, the placement of -l option does matter,
and it cannot compile successfully now. Libraries must be specified
after the objects in the linking command.
Also, there is another option -pthread which seems more preferred.
