Since CMS upgrd. “protected content” page returns status 403

[10010110]

I updated the CMS to the latest version (1.11.12) and all of a sudden my page that is set to “protected content” (FEU provides that method) is returning status 403 (Forbidden). The Frontend Users module is version 1.25.1. As soon as I change the content type of the page to regular content it shows up.

I submitted that as FEU-related bug report because I thought that would be the reason but calguy1000 wouldn’t accept that, so here I am.

I’ve cleared the cache, everything is up to date, PHP version is 5.6.4, mod_rewrite is not the issue because that happens with or without. And this happens on my local dev server as well as on the live site.
What could be the problem here? (Let me know if you need any more info)

Edit: I just downgraded back to CMS version 1.11.11 and it’s working again, so I really don’t know if that’s a bug in the CMS or in FEU. Until that is solved I can’t upgrade the CMS, apparently.

[Rolf]

Have you tried to set debug true in config.php and checked the error_log for any error messages?

[staartmees]

cmsms 1.11.12 + FEU 1.25.1 + PHP 5.6.4: no problems

Cms Version: 1.11.12

Installed Modules:

CMSMailer: 5.2.2
FileManager: 1.4.5
MenuManager: 1.8.6
ModuleManager: 1.5.8
News: 2.14.4
nuSOAP: 1.0.2
Search: 1.7.11
ThemeManager: 1.1.8
TinyMCE: 2.9.12
CustomContent: 1.10
Play: 0.5.2
FormBuilder: 0.8
LinkMgr: 2.0
FrontEndUsers: 1.25.1
CGExtensions: 1.44.5
Gallery: 2.0.1
CGCalendar: 1.14.5
CGSimpleSmarty: 1.7.4
CMSPrinting: 1.0.5
ExtendedTools: 1.3.3
Notifications: 1.1
Captcha: 0.5.0
Showtime: 3.4
RSSSimplePie: 1.0


Config Information:

php_memory_limit:
process_whole_template:
max_upload_size: 96000000
url_rewriting: mod_rewrite
page_extension:
query_var: page
image_manipulation_prog: GD
auto_alias_content: true
locale:
default_encoding: utf-8
admin_encoding: utf-8
set_names: true


Php Information:

phpversion: 5.6.4
md5_function: Aan (Waar)
gd_version: 2
tempnam_function: Aan (Waar)
magic_quotes_runtime: Uit (Onwaar)
E_STRICT: 2048
E_DEPRECATED: 0
memory_limit: 128M
max_execution_time: 50
output_buffering: Aan
safe_mode: Uit (Onwaar)
file_uploads: Aan (Waar)
post_max_size: 96M
upload_max_filesize: 96M
session_save_path: Geen controle omdat 'open_basedir' actief is
session_use_cookies: Aan (Waar)
xml_function: Aan (Waar)
xmlreader_class: Aan (Waar)


Server Information:

Server Api: cgi-fcgi
Server Db Type: MySQL (mysql)
Server Db Version: 5.5.41
Server Db Grants: Er is een "GRAND ALL" permissie gevonden, alles lijkt in orde.
Server Time Diff: Geen tijdverschil aangetroffen

[Rolf]

Change the content_type of the page with the FrontEndUsers module tag to the regular content type. Try again.

[cfarrwake15]

this is happening for me too. any resolution?

[cfarrwake15]

you may have figured out by now, but i did find a note that you change the content type to error page and then the created page will show (login or whatever)

[jack4ya]

Yes... But what is the point of a protected page then.

[velden]

Checking whether the visitor is logged in or not. If not raise an error (http 403) and redirect to a login page (which itself should not be of type protected content!)

[jack4ya]

I meant what is the point of protected pages, at this point, if you can't use them and thus revert to a generic 403 page.

I opted to use the custom content instead, but being a ML side I would like to keep this as simple as possible.

Anyway, I can confirm the issue/bug.

[velden]

I meant what is the point of protected pages, at this point, if you can't use them and thus revert to a generic 403 page.

Create a CMSMS page of content type 'Error page', make sure to select Error Type: 'Page Forbidden (403)' and in the content type '{FrontEndUsers}'

Visitors that hit the Protected page without being logged in already will be 'redirected' to this Error 403 page an can login.

Might seem complex but I think it's neat to send a proper http error. Especially when using other authentication methods than the default FEU form.

EDIT:
I would like to mention that this change of behavior is implemented because of a vulnerability issue in the previous versions.

[jack4ya]

So that 403 would have:

If you are a groupA user login here
<formA returnto= pageA depending on lang X or Y or Z or ....>

if you are a groupB user login here,
<formB returnto= pageB depending on lang X or Y or Z or ....>

if you are a groupC user.... etc...

That's ... er... well... There must be a better solution?

[ren0r]

Same issue here. The workaround with that 403-Error-Page works fine for me.

But there still may be some problems with the FEU-Module. In my case, see the attached screenshot, the options within the configuration have been changed or got lost in other reasons to the new version.