Update access check is false in setting.php but update.php is still accessible anonymously!

on Drupal 7.4 fresh installation update.php? worked just as normal, updated the db and showed the update.php?op=results page with this reminder

Reminder: don't forget to set the $update_free_access value in your settings.php file back to FALSE. However, setting.php update free access reads false!

Comments

mdupont’s picture

If it's confirmed, then it's indeed critical. However I couldn't reproduce the bug

I tested the behaviour on a local Drupal 7.4 installation:
- checked $update_free_access is set to FALSE
- went to the front page of the site and logged out
- visited update.php
- got Access Denied as it should

Are you sure you hadn't an active session that was still open with user #1?

Damien Tournoud’s picture

Status: Active » Postponed (maintainer needs more info)
Anonymous’s picture

Strange! My site shows access denied now but I tried it several times before posting it here and it was accessible.

I guess we need more people to test this anyhow.

Anyone?

Damien Tournoud’s picture

Category: bug » support
Priority: Critical » Major
maggielanoue’s picture

hello - I am VERY new with Drupal but have been working to learn since January and taken about 300+ pages of notes to myself with links. I am trying to learn how to keep the different versions of my sites - development, staging and live - in sync - and trying to learn bash commands in terminal to do this.
Haven't gotten too far with that.

But I had this SAME THING happen today on my local staging site. I did updates, logged out, reviewed the update.php file to be sure the $update_free_access value read false (it already was like it was last time!)
then I went to my site - (had to take it out of maintenance mode) hit refresh a couple times - double checked I was indeed logged out -
went to the update.php file - and I got this drupal page that says: "Use this utility to update your database whenever a new release of Drupal or a module is installed." with the friendly drupal drop like I was logged in but I wasn't!
is this what you are talking about? is this a bug?

as I learn things I try to share back. obviously i am not too far along. but if anyone can share basic terminal commands for drupal so I can get into drush etc that would be great. I'm sure there is a link for that. I do have a book coming "The Mac OS X Command Line: Unix Under the Hood . " will be studying with highlighter and post it notes in hand.

mdupont’s picture

Did you try to actually go trough the steps of update.php when you went to it the 2nd time (when you were logged out) and did it work? Did you try to hit Ctrl+F5 to bypass your browser's cache and fetch the page from Drupal, or tried to access update.php from another browser/machine?

maggielanoue’s picture

mdupont - I suspect it was a matter of browser cache. Wish I had seen your comments or something like it before I posted. I thought I accessed through another browser but I cannot remember for sure. I did make a note of your tips in my files and I will also write back next time I get to this point - to confirm which way it went. Is the control f5 for macs and PCs? I could just clear browser cache manually and try another browser and make a note of it to verify that I did take those steps. Those things ought to be the first thing mentioned with this type of issue. Thank you.

Nantie’s picture

Does anyone know if this problem has been resolved? I have also run the update without problems. I went to change the settings.php file, but the $update_free_access was set to FALSE already. I am still able to access the update.php anonymously - and this is across different browsers. Even after clearing the cache. Any ideas?

cweagans’s picture

Priority: Major » Normal

Support requests are never major or critical.

dddave’s picture

Status: Postponed (maintainer needs more info) » Fixed

"Time" seems to have fixed this. Closing old, stale issues. If the issue still persists feel free to re-open.

Heine’s picture

For stragglers:

Note that if you use an opcode cache it may be possible that a prior version of the file that grants access is in effect. This happens with APC if you set apc.stat to off.

Automatically closed -- issue fixed for 2 weeks with no activity.