Brand new fresh install of gallery 3.09
first time login I get this error:
We tried really hard, but it's broken.
Talk to your Gallery administrator for help fixing this!
and the gallery3/var/logs has this:
<?php defined('SYSPATH') or die('No direct script access.'); ?>
2014-02-06 19:59:05 +00:00 --- error: Kohana_Exception [ 403 ]: @todo FORBIDDEN
/srv/www/htdocs/gallery3/modules/gallery/helpers/access.php [ 202 ]
#0 /srv/www/htdocs/gallery3/modules/gallery/helpers/access.php(425): access_Core::forbidden()
#1 /srv/www/htdocs/gallery3/modules/gallery/controllers/login.php(31): access_Core::verify_csrf()
#2 [internal function]: Login_Controller->auth_ajax()
#3 /srv/www/htdocs/gallery3/system/core/Kohana.php(331): ReflectionMethod->invokeArgs(Object(Login_Controller), Array)
#4 [internal function]: Kohana_Core::instance(NULL)
#5 /srv/www/htdocs/gallery3/system/core/Event.php(208): call_user_func_array(Array, Array)
#6 /srv/www/htdocs/gallery3/application/Bootstrap.php(67): Event_Core::run('system.execute')
#7 /srv/www/htdocs/gallery3/index.php(116): require('/srv/www/htdocs...')
#8 {main}
2014-02-06 19:59:05 +00:00 --- error: Missing messages entry kohana/core.errors.403 for message kohana/core
I have no idea what's wrong with this, can anyone assist?
Posted: Thu, 2014-02-06 20:01
Posts: 29
Sort of a "me too" post. I just found out that no one has been able to log in for weeks. My install is not new, so I am guessing a patch at some point of mysql or php might be an issue.
My 3.0.9 was working for at least a month back when I was still uploading to it. The pages all load, I just can't log in.
Version: 3.0.9
Operating system: Linux 3.11
Apache: Apache/2.4.6
PHP: 5.4.20
MySQL: 5.6.12
None of the logs seem to indicate much to me. Other than the path, my log entry is identical to the above post. If anyone can point me towards more logs to post, I'd be happy to do so.
Posts: 15
Actually dpetrak, that's the EXACT issue I had!
I ran gallery, quite literally for YEARS! Then POOF!
Logins just suddenly stopped working.
I figured something was wrong, so I did a fresh install from scratch, totally clean.
And this clean fresh install has the same issue.
it's totally broken.
2 days now and no response from gallery support.
I suggest you check out coppermine and zenphoto
Posts: 27300
must be a host thing that we can't reproduce. Seems it is failing a cross site scrip forgery checks. Perhaps your host made a change. As we don't install timers in the software to blow up.
Sorry for the late free response but the community is _ALL_ volunteers.
Not sure how much effort you want ot go to debug this ......
Seems you've made up your mind already about what free open source product you want to use.
Dave
_____________________________________________
Blog & G2 || floridave - Gallery Team
Posts: 29
Hi Dave, thanks for the suggestion. Do you think this might apply? I think perhaps the Apache install was updated in my case...
https://httpd.apache.org/docs/trunk/env.html#fixheader
I'm not the most adept with code, but I'll start looking... maybe I'll get lucky.
****
Update: The above Apache header workaround didn't seem to help.
Posts: 15
I run my own server, so the "host" is me.
No changes were made, everything else works just fine.
I'd love to spend time debugging, if I had any idea what to look at.
I'm not a coder so I have no idea what these error messages me.
there is nothing on the host that checks for CSS forgery or other things.
it's default apache with mod_rewrite enabled.
ran for years, suddenly stopped. Did a clean install, still same issues.
In fact, I even re-installed the server from scratch with the same OS, etc
and installed gallery from scratch on that and get the same error.
I don't know where to look for how to fix it.
/var/log/messages and apache logs dont contain anything.
the only logs are in gallery var/log refer to Kohana - which I also know nothing about.
I've google searched and checked through the forums.
I see other people posting online about this issue, but no follow-ups.
So please tell me where do I start in trying to fix it, especially seeing as i'm a non-coder
it could be as simple (and stupid) as file permissions on the server,
anything would be appreciated.
Posts: 29
Dave, do you think there is a single block of code I can comment out to disable the forgery check temporarily? Or is this pretty pervasive? I can't quite follow the code, it's a bit above my DOS scripting days, but I'd love to tweak and find out if this is really the issue.
Posts: 27300
If it worked before then "Something" changed. The code just does not change by itself.
Lets see if you can change the function that is complaining...
Edit gallery3/modules/gallery/helpers/access.php
about line 422
/** * Verify our Cross Site Request Forgery token is valid, else throw an exception. */ static function verify_csrf() { $input = Input::instance(); if ($input->post("csrf", $input->get("csrf", null)) !== Session::instance()->get("csrf")) { access::forbidden(); } }to
/** * Verify our Cross Site Request Forgery token is valid, else throw an exception. */ static function verify_csrf() { $input = Input::instance(); if ($input->post("csrf", $input->get("csrf", null)) !== Session::instance()->get("csrf")) { } }you might get a bit further in the app. then we can go from there.
Dave
____________________________________________
Blog & G2 || floridave - Gallery Team
Posts: 29
OK, I deleted the line
access::forbidden();
And I no longer get an error, but I also don't get logged in. Nothing logged in the current error log since the last time I tested this before your suggestion.
Posts: 15
Yeah I get the same thing, no more error, but also doesn't login.
hit login, and just takes you back to main page.
so it's something, but not quite enough.
nothing new added to var/logs either
but this might help:
[php5:error] [pid 9316] [client 192.168.0.4:52981] PHP Notice: Undefined index: g3_password in /srv/www/htdocs/gallery3/installer/installer.php on line 141, referer: http://192.168.0.4/gallery3/installer/index.php
Posts: 29
I put the line back in and reloaded to get back to where I was before. Hit F12 in Chromium which shows (as you probably guessed):
login/auth_ajax 500 (Internal Server Error)
I don't have anything in my php.errors file. (Cleaned those issues out, so nothing for today.)
Posts: 15
Hey! I just noticed something VERY odd about this!!
dpetrak, see if you can verify this! Pls!
I just noticed, that when I do the clean install of gallery3 and it fails to allow logins (get the kohana errors, etc)
that TWO very odd things happen (or rather don't)--
#1 - the "Welcome to Gallery" never shows up, it just takes you to the main screen with "login" in the upper right corner (and you can't login as mentioned).
And #2 as a result of this also:
#2 - the admin is NOT automatically logged in!
I'm not sure this helps debugging this or not, but hopefully it does.
I just noticed this because I did a clean install on another server with a different OS version of linux and
saw BOTH the "welcome" screen, and the fact it automatically logs the admin in after install.
Neither of these happen with the primary server. So there's definitely something there.
deptrak I'm attaching a screen capture of the welcome message. Can you try reinstalling and see if it pops up or not? My money is on not!
it's such a small thing I never noticed it. Also check the auto-login, I'm betting it doesnt happen for you either.
see attached
Posts: 29
I'll check on that as soon as I can. Can you gather all the version data for your two installations like I did in my first post?
Posts: 15
gallery 3.0.9
Linux: currently 3.13.1
mysql Ver 15.1 Distrib 5.5.33-MariaDB, for Linux (x86_64) using readline 5.1
PHP 5.4.20
Apache/2.4.6
I've done some more testing,
since I have a system where gallery is working and the primary server where it isn't.
I've exhaustively tested what i can, and gotten nowhere.
I've tried (one at a time and finally in combination):
copying the apache config from the working machine - no effect
copying the php config from the working machine - no effect
copying the gallery3 data files (htdocs) and the sql database - also no effect
This is very very strange.
to put some possible differences in perspective, the working machine is using:
gallery 3.0.9
mysql mysql Ver 14.14 Distrib 5.5.33, for Linux (x86_64) using readline 6.2
php 5.3.15
linux 3.4.63-2.44-desktop
apache Apache/2.2.22
Posts: 15
floridave is there any way to figure out why the welcome message doesn't get displayed?
there's something wrong there, seems to be where things start to go wrong
Posts: 29
Might be the changes in Apache 2.4 then.
Posts: 15
dpetrak when you do a clean install on the problem system, do you get the welcome screen?
Posts: 27300
I'm no expert in this regard especially with sessions.
The code that redirects to the welcome message is done with sessions:
if ($session->get_once("after_install")) { $content .= new View("welcome_message_loader.html"); }So it seems that the get_once function is not working properly.
Digging further the Kohana Session class has:
public function get($key = FALSE, $default = FALSE) { if (empty($key)) return $_SESSION;I could be wrong but $_SESSION is a php superglobal so I guess you can see if that works with a test script.
Also Make sure you redirect to the same domain. So redirecting from a www.yourdomain.com to yourdomain.com doesn't carry the session forward.
Dave
_____________________________________________
Blog & G2 || floridave - Gallery Team
Posts: 15
floridave,
I don't understand that at all.
My stuff is all local on one machine. so where would it be forwarding or redirecting to?
it seems like for whatever reason that if is failing, and other stuff.
is there a way to debug this? can i get it to display the value of $session or $_session ?
i'm not a coder, as i mentioned.
BTW I want to mention I also got gallery3 working for about a day on Mac OSX MAMP 2.2
after about a day I started getting the same errors, and var/logs kohana messages as linux.
My guess is that its a combination of the new apache as well as something in mysql.
but that's a total guess at this point.
Posts: 29
I had a particularly long Monday at my day job... But I threw together a test install on the same server with a new database and folder. I have a success page which provided me an admin password, but i was no logged in. And when I tried to log in on the new install, I have the same error as we've described above.
Posts: 15
well there's a success page, but there's also a "welcome" page, which I attached.
Did you watch closely enough to see if you got that one?
the admin not logged in is a real key.
Maybe floridave can figure out why that's not happening, or how we can debug that.
Posts: 27300
Now your getting outside my comfort zone. I don't like arrays and session troubleshooting.
Anyway add:
<pre><? print_r($_SESSION); ?></pre>to the page.html.php file of the theme you are using. Just below the
<body <?= $theme->body_attributes() ?>>line.When you browse the page there will be a bunch of text of the array. Scroll down to where it says something like:
It will be just before the gallery page is rendered.
Note that number and browse to a different album or photo. That number should not change.
If you don't get any text then your PHP is not set up properly as $_SESSION is a super global. http://www.php.net/manual/en/reserved.variables.session.php If the csrf changes then the reason is over my head and perhaps some server expert can chime in.
If it does change then we need to investigate why.
Remember to remove that bit of code as it exposes the CSRF value and might be a security risk.
Dave
_____________________________________________
Blog & G2 || floridave - Gallery Team
Posts: 29
The value does change on each page load for me.
Posts: 15
Yep it changes every time for me as well.
the previous change to access.php when you hit login and enter correct info,
just takes you back to the same page, doesn't actually log you in.
the login functions are totally borked
Posts: 15
floridave - here's a weird idea:
is there a way to change themes without having access to admin functions or logging in?
since login doesnt work, maybe it's specific to the default theme.
Posts: 27300
Well there's the problem. Sessions should not change.
Sure just rename the themes directory to the current theme and rename the current theme to something else.
Dave
_____________________________________________
Blog & G2 || floridave - Gallery Team
Posts: 27300
Googleing I found some issue with Byte Order Mark
Please check http://validator.w3.org/i18n-checker/ and see if you get 'Byte order mark (BOM)' set to 'No'.
Dave
_____________________________________________
Blog & G2 || floridave - Gallery Team
Posts: 27300
Also check that your php.ini session.save_path is a place that has write permissions for the php/webserver.
Dave
_____________________________________________
Blog & G2 || floridave - Gallery Team
Posts: 15
BOM is No, and session.save_path is writeable
using UTF-8 here if that matters
that validator says "no issues to report"
btw with the previous change for the "if" statement,
when that line is removed, there are no errors recorded anywhere,
it just doesn't login.
Posts: 27300
Sessions should not change. That is why you can't login. Your googleing skills are about as good as mine at this point as I'm out of ideas why the session is not saved/kept/persistent across different pages.
Dave
_____________________________________________
Blog & G2 || floridave - Gallery Team
Posts: 29
So I noticed that a Joomla site on the same server had the same issue. I turned off using the database for sessions, and that resolved the issue on that site. So it looks like it's mysql related. I have nothing in the sessions table. Using the same user to poke around from the command line as is set up for gallery I have no issues. I checked grants and that user has all privs on the database.
Any idea what a mysql upgrade would have buggered up?
Posts: 15
not sure what broke.
seems something between mysql and mariadb as well.
as I mentioned earlier, its definitely related to the database.
Posts: 27300
That seems to be a common issue.
Time for bed for me.
Dave
_____________________________________________
Blog & G2 || floridave - Gallery Team
Posts: 15
Well that doesn't work.
I completely uninstalled mariadb, manually deleted the files,
deleted the gallery,
did a fresh install of mysql, and gallery,
and same problem!
now, still the fact the "welcome" screen never shows up really bothers me,
and then it doesn't login and you can't login.
it's very badly broken with new apache and new mysql.
BTW I tried with other themes as well, made no difference.
I think I've exhausted everything I can do, unless someone has a bright idea.
Posts: 27300
Sorry I don't know how to fix sessions that don't get passed/saved properly. Perhaps someone has a different idea.
Dave
_____________________________________________
Blog & G2 || floridave - Gallery Team
Posts: 29
I was on Oracle's mysql, but just swapped over to the latest mariadb. still the same issue. Still trying...
Posts: 120
Have been following this thread out of interest. The only thing I can add is that if Apache were set to expire sessions really quickly (like 1 second), could this result in the behaviour mentioned here? http://httpd.apache.org/docs/trunk/mod/mod_session.html
Posts: 120
And this page mentions mod_urlrewrite as a cause.
http://stackoverflow.com/questions/15986662/php-apache-sessions-not-sticking
It may have something to do with the modules you are using in Apache.
Posts: 29
Hey spags, thanks for the ideas. I wasn't using mod_session at all, but tried it just in case, and that made no difference. I also tried disabling mod_rewrite, but the site still had the same issue.
Posts: 1857
Is your session.save_path properly set on the server? What are the permissions on that path's directory?
Also, a known issue with php 5.4 and suhosin: https://github.com/stefanesser/suhosin/pull/26
I think (but not 100% sure) that $_SESSION is mostly php, but, having said that, have you checked mod_session_dbd?
EDIT: Specifically, have you looked at http://httpd.apache.org/docs/trunk/mod/mod_session_dbd.html#sessiondbdcookieremove
Posts: 29
Thanks for the suggestions, here's what I tried:
session save path is set as normal, and permissions seem fine on that folder. the apache user has access.
I tried disabling suhosin and still got the same issue. No errors are being reported.
I'm wondering if PHP can't talk to the database for some reason. I haven't found any errors logged, and no one else seems to have this issue. I'm starting to think it is time for a new server.
Posts: 1857
Maybe try moving back to Apache 2.2. (Apache did make a number of changes with session handling starting in 2.3, but I haven't used anything past 2.2 with Gallery installs, so I'm not sure if those changes are where the break is.)
I'm using php 5.4 in some environments that had success with Gallery, so I don't think it's that. Of course, it could easily be the specific settings used.
It would be interesting to know if logins for other CMS systems (e.g. Wordpress, Joomla, Drupal, etc) work in your environment (just because I'm curious), but yeah, a new server (or at least a new server setup) may be the fastest resolution.
Posts: 29
Yes, I stated above Joomla had the same issue, but since no one logs in to change that site very often, I never heard about it. That site now works if I don't use the database for session handling.
I'll look into downgrading apache later tonight.
Posts: 29
Ugh. Here's the deal for me.
I had previously tried just disabling suhosin, but the fact that it was installed at all was my issue. I have completely removed it and logins are working. Does anyone think I need to replace this with another security feature? If so, please make a recommendation.
And again, thanks to everyone who chimed in before. suhosin was one of the first things I tried before coming to the forum, but I had only set it to sim mode.
Posts: 27300
So you run suhosin and did not get a warning?
FAQ: Why am I seeing errors about suhosin.session.encrypt?
100s perhaps 1000s of settings to test for........Perhaps we can't get them all.
Dave
_____________________________________________
Blog & G2 || floridave - Gallery Team
Posts: 29
Yeah, there are no errors, though I have logging set pretty high. I tried suhosin.session.encrypt = off just for giggles and still have the issue.
I'm willing to spend as much time testing as you are, Dave. Hopefully that's finite
I don't know a lot about Suhosin... Just the general concept, really.
Posts: 27300
I don't even know the general concept. So lets hope others can come to some conclusion.
Dave
_____________________________________________
Blog & G2 || floridave - Gallery Team
Posts: 1857
@dpetrak: I'm assuming that you added the change to the correct file and that you restarted Apache after making the change.
Most of the solutions on the link I posted above are included in the link @floridave posted, but there are a few additional options as well. Outside of those, I wouldn't know what else to recommend.
Having said that, since you have control of the server, is upgrading your php to 5.5 not an option? That may be easier (and better in the long term) than trying to force php 5.4 to work.
Posts: 29
I'm pretty sure I had it in the correct file. I did restart Apache, yes.
I've been looking at upgrading to PHP 5.5 today, but my distro doesn't have the upgrade package right now, so I'm trying to research why, or if they plan to offer it soon. I think I'm out of time for tonight, so I'll pick it up again tomorrow.
Posts: 1857
FWIW: I can confirm that Gallery works properly with Apache 2.2.22 and PHP 5.4 without suhosin.
In the process of trying Apache 2.4.6 and PHP 5.4.20, but might not get it done for a few days, depending on schedule.
@dpetrak: If you can't move PHP up, maybe try moving Apache down? Not sure it'll help though since captaincapacitor reported using Apache 2.2.22 and PHP 5.3.
Honestly, I don't think I can help much more on this one.
I do hope you get it sorted though.
Posts: 29
It's been another long Monday. I think I'm OK without suhosin until I can at least get up to php 5.5. My distro doesn't have a package yet, but I'll check on what it could break elsewhere and see if I want to grab it anyway. I was checking versions, and session is mentioned in the last 5.4.25 release. If openSuse doesn't go to 5.5.9, perhaps they'll get to 5.4.25 and I can try suhosin again.
I don't allow anyone but a couple of family members to upload to gallery, and none of the other sites have admins that I think know how to upload... So I should be OK if php and suhosin are in conflict for a couple of months. But I'll certainly post back if I can try any newer version.
Until then, thanks again guys.