One answer to 257408 and several questions

Asked by Gerry Gilmore on 2014-11-30

Hi - I am evaluating quexs for use in several universities here in the USA and I have several questions to help me proceed.

First, though, in answer to 257408, the latest Ubuntu (and Debian?) apache2 packages appear to want everything to go into /var/www/html rather than /var/www as the current instructions indicate. That would account for his error.

To my questions:

1) Also related to the latest version of apache2 in Mint latest is that the apache directives have been rearranged somehow so that the entries referenced in the installation steps (Options FollowSymLinks, etc.) do not exist in 000-default.conf and trying to place them there does not work and I consistently get the "Server side authentication failed..." message.

2) This leads me to the bigger question, which is how "Users" (as defined by apache authentication) map into "operators" within quexs. Since there is no User Login within quexs, I presume that it relies exclusively on apache for authentication, but how does one become a certain Operator within quexs?

3) Similarly, there does not seem to be any authetication within quexs for Admin priveleges, how is this handled?

TIA, and - for the record - I'll be more than happy to update the install docs once I've got my arms around the process. I wrote a good deal of docs (and install/config scripts along with some C code) during my Dialogic days, most of which is still in use last time I looked. :-)

Thanks again,

Gerry

Question information

Language:
English Edit question
Status:
Solved
For:
queXS Edit question
Assignee:
No assignee Edit question
Solved by:
Adam Zammit
Solved:
2014-12-11
Last query:
2014-12-11
Last reply:
2014-12-11
Gerry Gilmore (gilmore-gerry) said : #1

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

Best Adam Zammit (adamzammit) said : #2

Hi Gerry,

Thanks for your questions and answers!

I think displaying the operator name is a good idea.

Regarding your question 3) - admin privileges are handled by authentication in the /admin directory - see the .htaccess.example files for details.

Regards,
Adam Zammit

Vladimir (jumboq) said : #3

Hi Gerry,
Thank you for answer to 257408

Gerry Gilmore (gilmore-gerry) said : #4

Thanks Adam Zammit, that solved my question.

Gerry Gilmore (gilmore-gerry) said : #5

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

Adam Zammit (adamzammit) said : #6

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

Gerry Gilmore (gilmore-gerry) said : #7

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.
>

Adam Zammit (adamzammit) said : #8

(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

Adam Zammit (adamzammit) said : #9

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