e107inc / e107

e107 Bootstrap CMS (Content Management System) v2 with PHP, MySQL, HTML5, jQuery and Twitter Bootstrap. Issue Discussion Room: https://gitter.im/e107inc/e107
https://e107.org
GNU General Public License v3.0
321 stars 213 forks source link

News posting "unauthorized access" #1245

Closed pricey1981 closed 6 years ago

pricey1981 commented 8 years ago

Trying to post a news item but getting a blank white page which simply says "unauthorized access". Works fine on WAMP server but not on live site. I am setup as main admin so can't be permissions? Also another admin with correct permission having same issue.

Any ideas?

willem010 commented 8 years ago

confirmed.
i have this issue on 3 differebt sites. usually when image is inserted.. but i cant say thats the cause. the text is correctly saved to db tho.

tgtje commented 8 years ago

related to #1218 ?

pricey1981 commented 8 years ago

yes, same error, different circumstances. Also, the error I'm receiving is on posting any news item, not just if image is inserted as suggested by willem010. News isn't even added to the db.

tgtje commented 8 years ago

Can not really replicate ( wamp multiple php versions + live), so for time being i would suggest (only as test) to rescan plugin folders and or dbase scan.

willem010 commented 8 years ago

i mixed up 2 issues.. sorry.. sometimes posting news results in an err500 but the text is saved. this usually is when images are inserted. ( and it may not be related .. but happens on the same 3 sites where this issue also happens..)

the unauthorized access issue is just like this one. no data is saved. no relation to images. (it takes a few attempts to get it to work add some persistance.. and in the end the item is posted...)

CaMer0n commented 8 years ago

Some things to try in your e107_config.php file:

 define('e_TOKEN_FREEZE', true);

If that does nothing, try this:

   define('e_SECURITY_LEVEL', 0);  (not recommended for production server)

There should also be an unauthorized access log in the e107_system folder, it could provide clues.

pricey1981 commented 8 years ago
define('e_TOKEN_FREEZE', true);

added this line and it worked once, but now reverted to same issue

extract from the log file (I've removed my IP from [RemoteAddr] and [HttpXForwardedFor])

REQUEST_URI: /e107_admin/newspost.php?mode=main&action=create
e-token (POST): a3e04d19d95abfa0db5cfdf41e5c2433
_SESSION:
Array
(
[e107sess] => Array
    (
        [_session_validate_data] => Array
            (
                [RemoteAddr] => 
                [HttpVia] => 
                [HttpXForwardedFor] => 
                [HttpUserAgent] => Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.86 Safari/537.36
            )

        [language-list] => 
        [challenge] => 57a7f8e83d546796319e12bbee2c0478073095e9
        [prevprevchallenge] => 57a7f8e83d546796319e12bbee2c0478073095e9
        [prevchallenge] => 57a7f8e83d546796319e12bbee2c0478073095e9
        [ubrowser] => 785206e5cec747755d4c7ecee79ff9dc
        [__form_token] => bcbe7ce5c9a2ea5bd73092deb256a7585654b2291950b4.74140337
        [_system_messages] => Array
            (
                [error] => Array
                    (
                    )

                [warning] => Array
                    (
                    )

                [success] => Array
                    (
                    )

                [info] => Array
                    (
                    )

                [debug] => Array
                    (
                    )

            )

        [_previousUrl_expire] => 1448391536
        [_previousUrl] => /e107_plugins/tinymce4/plugins/e107/parser.php
    )

[_cookie_session_validate] => 1448412809

) die = true

pricey1981 commented 8 years ago

hmmmm, now getting the same unauthorized access message when trying to disable a welcome message

CaMer0n commented 8 years ago

Perhaps check the php info in admin to make sure session save path is okay. You could also try switching between cookies/sessions in the admin preferences area.

willem010 commented 8 years ago

adding the e_token line seems to help a lot. (we will keep you posted if other errors occur)

but.. while editing the config file i did notice a weird and unfamiliar line in there.. looks llike the gfm site was / is hacked?

(@cameron.. i did send you the ftp details on the e107,org site.. if you can, check it out.. it looks like a targeted e107 hack to me?

if you want me to post a new topic on that one let me know. )

willem010 commented 8 years ago

.. and more errors..

the e_token line works magic for at least 2 sites, but it ruined the gfm site.. images from the thumb.php script are no longer working.

in the media manager all thumbs are blank. all thumbs on site are no longer working.

i tried -

no results. (thumbs are created in cache folder and they seem ok.. they're just not showing)

but i guess this is going way off topic now.

edit 25-11 the server was hacked. exploit files found. probably causing all the errors on this domain. so.. for now.. do not mind the gfm issues.

Moc commented 8 years ago

@willem010 On the two websites that now work properly with the e_TOKEN_FREEZE enabled, can you check the 'session save path'? It should be listed in the About > PHP info section. Make sure that this is pointing to the right folder, and that this folder is writable.

willem010 commented 8 years ago

hmm.. thats pointing to a non existent folder. let's create it and see what happens.

Moc commented 8 years ago

That should do the trick :)

The "unauthorized access" error usually occurs when e107 does not recognize your session. The session data is stored in a (temporary) folder on your server (the session save path). If this folder does not exist, the session is not properly created, thus throwing the error due to security reasons.

Moc commented 8 years ago

@pricey1981 Please contact your hosting provider for the live website and have them check the PHP session save path (session.save_path). It should be existing and writable.

willem010 commented 8 years ago

makes a lot of sense. thanks!

does make me wonder tho.. why is this pointing to /tmp in the server root .. when this folder is not created?

Moc commented 8 years ago

@willem010 IIRC, that is the default session save path (set by PHP itself). The person configuring the server should make sure that the server environment is either able to use this folder, or change the configuration (PHP or server) in such a way that this is possible.

Some background info: http://stackoverflow.com/questions/4927850/location-for-session-files-in-apache-php (I need to read up on this as well haha)

willem010 commented 8 years ago

ah, now that i know.. won't happen again. ;)

and for those who want to know.

looks like the avatar upload function is the cause of the gfm site hack.

pricey1981 commented 8 years ago

session.save_path is set to /tmp and this folder exists and is writable. Unfortunately I'm still getting the same error

Moc commented 8 years ago

@pricey1981 Does this happen only on news items or also on other areas of your website (e.g. creating new pages)?

cameron commented 8 years ago

hey folks, take care when autocompleting @CaMer0n... :)

Moc commented 8 years ago

@willem010 Just to confirm. DId fixing the session save path solve your 'unauthorized access' errors? Did you remove the e_TOKEN_FREEZE line?

willem010 commented 8 years ago

still need to remove it. i will test tomorrow.

pricey1981 commented 8 years ago

@Moc happens when creating new pages too, and books/chapters

pricey1981 commented 8 years ago

Just playing around again, when I added e_TOKEN_FREEZE to the config file the first time I tried to add a news item it worked. But not after. I've just removed that line from the config file and it allowed me to post a news item. But trying to delete that item, I get the unauthorized access error again. I add e_TOKEN_FREEZE back into the config file and can delete the news item

pricey1981 commented 8 years ago

just in case this helps...

e107 CMS Log file : Unauthorized access Log   2015-11-26_07-44-23
-------------------------------------------------------------------------------------------

2015-11-26 07:44:23     debug       HOST: www.uknetrunner.co.uk
REQUEST_URI: /e107_admin/newspost.php?mode=main&action=list
e-token (POST): ac4827f01a14e1cdbbfd8645f19cfaf3
_SESSION:
Array
(
[e107sess] => Array
    (
        [_session_validate_data] => Array
            (
                [RemoteAddr] => 
                [HttpVia] => 
                [HttpXForwardedFor] => 
                [HttpUserAgent] => Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.86 Safari/537.36
            )

        [language-list] => 
        [challenge] => 82e5725ebbe40a097c4ba027251e7332e97797db
        [prevprevchallenge] => 82e5725ebbe40a097c4ba027251e7332e97797db
        [prevchallenge] => 82e5725ebbe40a097c4ba027251e7332e97797db
        [ubrowser] => 785206e5cec747755d4c7ecee79ff9dc
        [__form_token] => ff4b0932d74b89172c3a92000559ed625656b853d8e9e2.60404460
        [_system_messages] => Array
            (
                [error] => Array
                    (
                    )

                [warning] => Array
                    (
                    )

                [success] => Array
                    (
                    )

                [info] => Array
                    (
                    )

                [debug] => Array
                    (
                    )

            )

    )

[_cookie_session_validate] => 1448545459
)
die = true

---------------------------------

2015-11-26 07:46:35     debug       HOST: www.uknetrunner.co.uk
REQUEST_URI: /e107_admin/newspost.php?mode=main&action=list
e-token (POST): 8d924e19a59d11b30990f3b62e775f21
_SESSION:
Array
(
[e107sess] => Array
    (
        [_session_validate_data] => Array
            (
                [RemoteAddr] => 
                [HttpVia] => 
                [HttpXForwardedFor] => 
                [HttpUserAgent] => Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.86 Safari/537.36
            )

        [language-list] => 
        [challenge] => 2a531485190a8cc55ac2f36c2370a44e482afb39
        [prevprevchallenge] => 2a531485190a8cc55ac2f36c2370a44e482afb39
        [prevchallenge] => 2a531485190a8cc55ac2f36c2370a44e482afb39
        [ubrowser] => 785206e5cec747755d4c7ecee79ff9dc
        [__form_token] => 5c0eb187ed05c30b56e178269ec90af45656b8d9333303.00179923
        [_system_messages] => Array
            (
                [error] => Array
                    (
                    )

                [warning] => Array
                    (
                    )

                [success] => Array
                    (
                    )

                [info] => Array
                    (
                    )

                [debug] => Array
                    (
                    )

            )

    )

[_cookie_session_validate] => 1448545593
)
die = true

---------------------------------
willem010 commented 8 years ago

@Moc a quick test and everything looks fine, we've created a page and newsitem with no problem.

we still need to check what happens when the admin takes a lot of time composing his item tho. (the siteadmin told me the issue usually appears when he takes a lot of time to enter and edit. a quick edit almost never had an issue?)

anyway the siteadmin will look out for more problems. when something comes up we will let you know.

CaMer0n commented 8 years ago

@willem010 @pricey1981 Would you mind testing a change for me? Please enable debug of Paths + Variables. (ie. index.php?[debug=paths+] ) Under Session you should see some variables:

Session lifetime
Session domain
Session save method

Please share the values here. Thank you.

willem010 commented 8 years ago

Session lifetime 86400 seconds Session domain .my-domain.nl Session save method files

domain is edited. i'm not posting my clients domain here. ;)

pricey1981 commented 8 years ago

@CaMer0n I get the same as @willem010 (obviously my own domain, which is a .co.uk)

pricey1981 commented 8 years ago

@CaMer0n how do I switch the debug off?

willem010 commented 8 years ago

?[debug=all,unstick] ?[debug=all-]

CaMer0n commented 8 years ago

Please update and try setting the session.save_path.

Option to define the session.save_path (relative to e107's root directory) in e107_config.php:    
define('SESSION_SAVE_PATH','relative-path-to-folder');
example: define('SESSION_SAVE_PATH','../_sessions/');
Use the PHPInfo page in the admin area to check it has worked. 
Will only work if the path to the folder exists. 
CaMer0n commented 8 years ago

If the "unauthorized access" is showing up after submitted a form (which has been open for over 24 minutes) - please try adding this to e107_config.php to see if it helps.

ini_set('session.gc_maxlifetime', 3600); 
pricey1981 commented 8 years ago

@CaMer0n appears to be working now. Thanks.

willem010 commented 8 years ago

we will keep you posted. thnx!

CaMer0n commented 8 years ago

@pricey1981 great! Which specific changes fixed it for you?

pricey1981 commented 8 years ago

@CaMer0n just updating with the latest download from github. Although I still have the token_freeze comment in the config file - should I remove this?

Moc commented 8 years ago

@pricey1981 Yes please test when disabling the token freeze, by removing that line. It's useful to know if the issue then returns.

pricey1981 commented 8 years ago

Have removed the token freeze and can add news items ok, but can't delete.

pricey1981 commented 8 years ago

hmmm, maybe that was becasue I pressed the back button rather than re-loading the page. Items deleted ok now.

pricey1981 commented 8 years ago

Still getting "unauthorized access" when undertaking other admin tasks, such as updating user settings

Moc commented 8 years ago

@pricey1981 Did you try the ini_set('session.gc_maxlifetime', 3600); in your e107_config.php file as suggested by Cameron?

I'm not sure how much server configuration knowledge you have but on the live website, you'll need to take into account that the /tmp folder is not the one in public_html (or wwwroot). You'll need to contact your hosting provider in order to have them verify the session save path.

pricey1981 commented 8 years ago

@Moc , sorry, only just seen your post. No, I didn't not try Cameron's suggestion as I am getting the error when the form has been open for only a very short period of time, e.g. less than one minute.

As I said above session.save_path is set to /tmp, which is in the non-public root, and this folder exists and is writable.

willem010 commented 8 years ago

i just ran into this issue again where i got unauthorized acces when trying to edit an (very old) news item. as soon as i tried to save an edit i was thrown out with unaut. acces i was unable to save the item in any way.

the body text had an old image in there which didn't exist at that url, and i was trying to get that edited but i wasnt allowed. any changes to this news item threw an error. not just a change to the url. in most cases i needed to login again to gain acces to the admin section again.

but .. after getting tired of being thrown out, i decided to edit the image directly in the database, as soon as i did this, i was allowed to edit the item using the admin section again. so .. it looks like an image which isnt working (in the main body text of a news item) is creating an issue here.

btw, the admin logs shows lines pretty much the same as what @pricey1981 posted, but does mention the tinymcse parser as prevous url. thats why i entered this here. (but there is another issue i think is pretty much the same.)

CaMer0n commented 8 years ago

Thank you @willem010 - this is a good clue!

pricey1981 commented 8 years ago

@CaMer0n any further progress on this?

As a test, I have set up a fresh install of e107 in a subdirectory of my live site. I appear not to receive any errors with this install which leads me to believe it is not server based. My live site was an upgrade from e107 v1. I'm assuming therefore, on the presumption that the v2 files have overwritten v1, that this is something to do with the DB? Or, might it be possible that there is a legacy v1 file causing a conflict?

pricey1981 commented 8 years ago

I've manually replaced the contents of SitePrefs in the e107_core table of my live site with the data from the newly installed dummy site. I no longer get the unauthorized access error. I will now setup the site preferences again to see if this resolves the issue. It seems it might be to do with some legact settings in this table/record

CaMer0n commented 8 years ago

@pricey1981 Thank you!

CaMer0n commented 8 years ago

@pricey1981 https://gitter.im/e107inc/e107# in case you wish to discuss it.