AudioGuyWorkNotes
CssWork - parent
This is current problems/tasks/working notes.
To Do
- Gathering docs, understanding code
- Walk through all admin access in slash and see where javascript can be dumped, what other fixes needed
- Try minified javascript
- Solve htaccess problem for staff wiki
- Solve topic add problem
The htaccess problem
Put an htaccess file in the html folder for slash, as I have done hundreds to times before...and it did not work.
Specifically, it did nothing at all.
No error, just...nothing.
Nothing in log that revealed much.
A problem with debugging this is the presence of 'Varnish' a cache ahead of the server. However, in the end I am told this is not, on this particular server, doing anything but passing the requests through.
First problem noted was that in the main apache config, the directive AllowOverride None was in place. this prevents anything in htaccess files from overriding the main config. Changed to AllowOverride All. Still not working. Checked the local apache config in the site/sslashcott.org dir and saw that had another such directive. Changed that one. Still not working. Decided to give up on htaccess completely, and put the directives into the main apache file. Still not working.
Noticed, however, this in the slash apache config file:
# Fourth Apache phase: access control
PerlAccessHandler Slash::Apache::Banlist
PerlAccessHandler Slash::Apache::User
The slash apache module has taken control of the Apache access control phase.
I am pretty sure this means that ONLY the perl modules now can operate in that phase, as in apache 1.3, there is just a traversal through the different phases, and whoever handles the phase causes apache to go on to the next phase.
Tried to check the docs to confirm this, but apache has removed 1.3 docs from their site.
Finally found an old 1.3 source on a backup, grabbed the docs out of this, and read:
-- Apache breaks down request handling into a series of steps, more or less the same way the Netscape server API does (although this API has a few more stages than NetSite does, as hooks for stuff I thought might be useful in the future). These are:
- URI -> Filename translation
- Auth ID checking [is the user who they say they are?]
- Auth access checking [is the user authorized here?]
- Access checking other than auth
- Determining MIME type of the object requested
- `Fixups' --- there aren't any of these yet, but the phase is intended as a hook for possible extensions like SetEnv, which don't really fit well elsewhere.
- Actually sending a response back to the client.
- Logging the request
These phases are handled by looking at each of a succession of modules, looking to see if each of them has a handler for the phase, and attempting invoking it if so. The handler can typically do one of three things:
- Handle the request, and indicate that it has done so by returning the magic constant OK.
- Decline to handle the request, by returning the magic integer constant DECLINED. In this case, the server behaves in all respects as if the handler simply hadn't been there.
- Signal an error, by returning one of the HTTP error codes. This terminates normal handling of the request, although an ErrorDocument may be invoked to try to mop up, and it will be logged in any case.
Most phases are terminated by the first module that handles them; however, for logging, `fixups', and non-access authentication checking, all handlers always run (barring an error)
--
So in short, if perl decides to handle the 'access' phase, Apache cannot.
I am now 99% certain that I cannot use htaccess or any other access phase functions on the apache server with slash.
However, the slash system itself has all that is required to do this, I just need to find a way to use it.
And an looking now...
Proposed solution:
Slash always checks if a user is logged in early in the page generation process. Find that place, and modify it to redirect all users who are not logged in to a login page (which must be created.)
Tracing through code now...
http://perl.apache.org/docs/1.0/index.html
21:09 stderr Hmm... Can you use an AuthUser on a virtual host that acts like a proxy? NCommander audioguy, oh wait, you're using varnish NCommander You need a fucking hack in slash to make that work NCommander There's a sanity check I stabbed out that causes slash to act stupid when its varnished audioguy That is what I was afraid of. Wondering if there is a simple way to do the same thing in slash code. 21:10 NCommander I think the patch is on the master branch, if not, you need to grep for "X-Forwarded-By" in slashcode -- mechanicjay audioguy: is it borked? 21:45 mechanicjay Varnish is passing everything through audioguy It is getting in the way of me trying to debug a problem audioguy I am trying to use .htaccess files, it is not letting me see the real errors, audioguy Logs shows this: audioguy [Wed Mar 5 05:40:08 2014] [error] :Slash::Utility::Environment:/usr/local/lib64/perl5/Slash/Utility/Environment.pm:683:cannot getSkin for empty skid='' ;; Which was called by:Slash::Apache:/usr/local/lib64/perl5/Slash/Apache.pm:359 21:46 mechanicjay Varnish should not be caching anything for the slashcott domain. I'll double check right now
Minifed javascript for jquery
This has now been placed on slashcott as a test to see if it workable on the main site.
I simply replaced the file in
/usr/local/slash/plugins/Ajax/htdocs/images/jquery/jquery-1.3.2.js
with
/usr/local/slash/plugins/Ajax/htdocs/images/jquery/jquery-1.3.2.min.js
after backing the original up, of course:
[root@slashcode jquery]# pwd /usr/local/slash/plugins/Ajax/htdocs/images/jquery [root@slashcode jquery]# ls jquery-1.3.2.js jquery.autogrow.js jquery.textselection.js ui.sortable.js jquery-1.3.2.min.js jquery.elastic-1.6.js ORIGINALjquery-1.3.2.js ui.tabs.js jquery.autocomplete.css jquery.lazyload.js ui.core.js jquery.autocomplete.js jquery.metadata.js ui.draggable.js
The minified version is about 50% smaller.
57254 Mar 5 14:33 jquery-1.3.2.js 57254 Mar 5 14:30 jquery-1.3.2.min.js 120764 Mar 3 20:21 ORIGINALjquery-1.3.2.js