GLPI plugins not working on virtual host (Apache)


I've installed GLPI on a Ubuntu 14.04 server running the latest version of Apache2. It works fine until I create a virtual host to run GLPI. I'm able to log in, but once I try to hit any of my plugins, I get

[Thu Sep 22 10:57:42.016046 2016] [authz_core:error] [pid 11162] [client] AH01630: client denied by server configuration: /var/www/html/glpi/plugins/consumables/consumables.js, referer:

I've verified through multiple channels that my permissions on my folders are correct, and that my directives are set properly in my .conf file:

<VirtualHost _default_:80>
         DocumentRoot /var/www/html/glpi/
         ServerAdmin [email protected]
         ErrorLog /var/log/apache2/error.log
         CustomLog /var/log/apache2/access.log combined
         <Directory "/var/www/html/glpi/">
                    Options FollowSymLinks
                    AllowOverride All
                    Require all granted

I'm banging my head here (and I've read all the SO articles about this issue). Advice is welcome.



Your configuration is correct but... You are using "AllowOverride All" which means, any .htaccess file inside any directory under documentroot will override your settings. Set AllowOverride none or check all your .htaccess files, so your virtualhost looks correct but anything can override what you are showing us.

Even more /front is not defined anywhere in the configuration you show, so there must be an alias or something somewhere which points /front but you are not showing it either.

I also noted that the URL in the access log and the one in the VirtualHost ServerName directive, make sure you are configuring/checking the correct virtualhost also.

By : ezra-s

Why GLES20.glGetAttribLocation returns different values for different devices?

... because different devices will have different hardware for setting up binding tables, and in some cases may completely optimize out redundant computations and repack the used attributes to save space. This is exactly why the API has a function call for getting binding locations on the device at runtime; if they were deterministic constants you wouldn't need a run-time call at all ...

The fact it returns -1 isn't an error; it is just showing that the attribute isn't needed (e.g. defined, but can optimized out because it doesn't contribute to the fragment pixel color), so this shouldn't cause any problems.

However it does mean that you can't safely assume (e.g.) that a_Position is always attribute 0, a_Color is always 1, a_Normal is always 2, etc. If you've hard coded that in your code then it's entirely possible you are uploading the wrong data to each attribute. You must query the binding locations to get the binding numbers to use (or use the shader-side static binding added in OpenGL ES 3.x).

Which actual GL API call is setting the GL error state?

By : Isogen74

This video can help you solving your question :)
By: admin