One answer to 257408 and several questions

A quick update, but first my apologies for failing to RTFM regarding the relationship between "users" and "operators". :-)

For other Ubuntu/Mint users, be sure that you load the apache2-utils package as well as mod_auth_plain - I continued to get authentication erros until loading mod_auth_plain.

From a longer-term perspective, I believe that an internal login/logout routine would be best but at least I understand now how it works (a bit). :-)

Finally, I've made a small change in the operator home page to display the currently-logged-in user name if anyone is interested...It helped me a lot as I cycled through a couple of test users.

Thanks,

Gerry

Hi Gerry,
Thank you for answer to 257408

Thanks Adam Zammit, that solved my question.

Thanks again, Adam. I've made a couple of small changes to the code to display the currently logged-in username and I'm trying to integrate a separate login/logout procedure, especially to cover the admin login. I've encountered issues with session persistence...

If anyone is interested, let me know and I can submit the code once done.

Gerry

Hi Gerry,

It would be great if you could share this code once it is done. You could submit it as a branch using Launchpad/BZR or as a patch here - whatever you find easier.

Regards,
Adam Zammit

Adam,

Greetings, and Merry Christmas/Happy New Year/Happy Holidays! I wanted to
give you a quick update on my progress (and lack thereof :-)) so far on the
expanded login/logout support. First, by way of background, I must confess
that I am in the process of learning PHP, though I do have a very deep and
broad experience with C (including a couple of device drivers) and shell
scripting. (Oh, how I yearn for a basic 'set -x' in php to avoid yet
another white screen of death...:-))

As I saw from some of your comments in the code in get_operator_id(), I
decided to use session variables - validated via DB lookup, etc. - instead
of PHP_AUTH_USER which has well-documented issues with basic logout
support. After extensive head-banging, hair-pulling and numerous tests and
print statements, I verified that, at least in my environment, session
variables (specifically, I am using $_SESSION['USER'] for testing) are
truly global as they are documented to be, except within the included
functions from functions-operator.php, specifically, get_operator_id(). I
have added the required session_start() calls at the very beginning of each
php file, including the includes though - again, according to docs,
includes are treated as in-line code and are in-scope - and yet, every
single time, calls to (isset($_SESSION['USER']) within get_operator_id()
fail and, of course, printing the string yields a null string. Here's what
I've got at the start of index.php and the includes (the includes and other
php files only have the session_start(), of course), though I've tried with
and without with identical results for the includes....
<?php
session_start();
$_SESSION['USER'] = 'test'; // GFG Hard code for most basic testing....
.....

I'm not trying to use you as a tech-support forum, and I'm wrestling
mightily trying to figure this out, but I wanted to give you an update as
we plan to base our product around quexs and I hope to be able to
contribute to the project as we move forward. Also, of course, if you
validate or refute what I'm experiencing, that would help my understanding.
:-) I can send you my output from phpinfo() if that will help also. (Also,
as an old-school tech geek, it's very frustrating for me to see what is
very well-documented behavior of global variables and their scope appear to
be so horribly broken.)

Anyway, let me know if you have any questions or feedback, and - thanks for
creating and maintaining such a great package! The functionality is exactly
what we've been searching for for performing longitudinal social-science
research studies.

PS - I am working on some additional documentation regarding installation
and configuration (stuff like needing to load the authz_groupfile module in
apache, etc.) and as it evolves I'd love to get your feedback on it. Not to
toot my own horn too loudly, but my installation and configuration scripts
are still being used by the former Intel/Dialogic telecom group for some of
their products. I'm also very familiar with the freeswitch project, and I
worked with Mark Spencer Himself(TM) on the initial asterisk dialogic
driver, so I hope to be able to help with the CTI aspects as well,
especially as I get more comfortable with PHP.

Thanks again,

Gerry

On Sun, Dec 14, 2014 at 8:12 PM, Adam Zammit <
<email address hidden>> wrote:

> Your question #258431 on queXS changed:
> https://answers.launchpad.net/quexs/+question/258431
>
> Adam Zammit posted a new comment:
> Hi Gerry,
>
> It would be great if you could share this code once it is done. You
> could submit it as a branch using Launchpad/BZR or as a patch here -
> whatever you find easier.
>
> Regards,
> Adam Zammit
>
> --
> You received this question notification because you asked the question.
>

(Sent directly to Gerry but also posted here for others)

Here I use this apache module:

http://home.digithi.de/digithi/dev/mod_auth_cookie_mysql/

This allows for apache to handle the authentication and then it can be set in a directory based manner that queXS expects.

Alternatively if you are using Apache 2.4 - this module may also work (Although I haven't tested it)

https://httpd.apache.org/docs/2.4/mod/mod_auth_form.html

Due to the implementation of queXS with Limesurvey - there are some complexities with using session based authentication - the session_destroy issue is one, but also Limesurvey within queXS has been modified to accept directory based authentication as the method for administrator authentication. This issue would also have to be resolved. If you are using Apache as the web server - I'd suggest trying the above modules and hopefully these will make things more straightforward.

If this kind of implementation is not possible - please let me know and I'll give some more thought to how to use strictly PHP based authentication.

Regards,
Adam Zammit

Also Gerry - regarding your additional documentation - I am very happy to give you feedback and would greatly appreciate if you were willing to share it with the community.

Adam