Well ... where to start here ... you have an interesting approach though ...
auth-user-pass-verify http://127.0.0.1/index.php via-env
When it was said 'script' or 'scripting', this wasn't exactly the idea. However, it's an intriguing idea to support authentication over an XML-RPC or REST API via http(s) - but OpenVPN doesn't support that.
I have no idea how this really works out in Windows, but I'd presume something similar could work in Windows
if it exists a command-line binary for PHP in Windows.
You would probably need a wrapper batch file (or cmd file), which says something like this:
@C:\Full\Path\To\PHP\php.exe C:\Full\path\to\your\openvpn-auth\index.php
Save this somewhere close to your openvpn configs as openvpn-auth-wrapper.bat ... and modify your auth-user-pass-verify option to say something like:
auth-user-pass-verify openvpn-auth-wrapper.bat via-env
You might need a full path to this bat file as well, I dunno.
It might even be that you can do this, avoiding the bat file all in all, but I don't know how that will work out:
auth-user-pass-verify "C:\Full\Path\To\PHP\php.exe C:\Full\path\to\your\openvpn-auth\index.php" via-env
It's also a while since I played with auth _scripts_ (I'm mostly doing things in C, using --plugin these days) ... so I don't recall now if it was needed to return with "exit code" 0 or 1 ... or if it is enough to "echo 0" or "echo 1" from your PHP script. But 'exit code' usually means using the exit() function, and I then would be careful about using 'echo' at all.
Another thing ... your auth script might be vulnerable to an SQL injection. There are many tricks how to avoid the parsing of mysql_real_escape_string() and such likes. However, mysql_real_escape_string() makes it harder than many of the alternatives. But if you start playing jokes with multi-byte characters, it's often odd and hidden ways to avoid such escapes. You can find an old example here:
http://bugs.mysql.com/bug.php?id=8378 ... Prepared statements is the only sane approach which provides a far better safeguard against such attacks (unless it's a bug even deeper in the SQL engine). See this URL about prepared statements with MySQL and PHP:
http://php.net/manual/en/mysqli.prepare.php
