Protected Content Page

I have created a content page and only allowed for a specific member group to access it (logged in users). However, if a non-logged in user access the page they see a 404 page instead of being redirected to a login screen like I would have expected. Is this not possible with CS Cart?

I want to put a link to this protected content page on the website for logged in users to access. Anyone not logged in would think it's a broken link since they are brought to the 404 page.

Not really. The cart doesn't know if the problem is with a logged in user not in the needed group or simply not logged in. Note that "registered users" is effectively a usergroup in cs-cart. If you redirected and the problem was the specific usergroup, you'd end up in a redirect loop.

If this is a one-page type of affair, you could handle the redirect to login with the page as the return_url by using a pre controller.

I have created a content page and only allowed for a specific member group to access it (logged in users). However, if a non-logged in user access the page they see a 404 page instead of being redirected to a login screen like I would have expected. Is this not possible with CS Cart?

I want to put a link to this protected content page on the website for logged in users to access. Anyone not logged in would think it's a broken link since they are brought to the 404 page.


app/controllers/frontend/pages.php

try to replace
        return array(CONTROLLER_STATUS_NO_PAGE);
with
        if (!empty($auth['user_id'])) {
             return array(CONTROLLER_STATUS_NO_PAGE);
        } else {
            return array(
               CONTROLLER_STATUS_REDIRECT,
               'auth.login_form?return_url=' . urlencode(Registry::get('config.current_url'))
            );
        }
It can be done with the My changes module also (use post controller)

(!) Not tested

and then you'll never see a real 404 and you'll end up in a redirect loop as I stated above.

and then you'll never see a real 404 and you'll end up in a redirect loop as I stated above.

Why do you leave pages with 404 URLs on your website? :)

Obviously no one would do that intentionally but the poor user who gets trapped in the redirect link will never be able to accurately report it to the merchant. A bit more logic would be required to do it correctly. I.e. identifying why the page won't load before redirecting. Another use case is that the user us logged in but not in the needed usergroup and so the change above redirects them to login again....

I was simply pointing out the effects of the recommended change. If the merchant is comfortable with that, have at it. But I would not recommend it.

Update: My oversight! I just noticed you had conditionally done the redirect by checking if user was logged in or not first. So your code above should be fine (though it does alter a distributed file which is never a good thing).

Not really. The cart doesn't know if the problem is with a logged in user not in the needed group or simply not logged in. Note that "registered users" is effectively a usergroup in cs-cart. If you redirected and the problem was the specific usergroup, you'd end up in a redirect loop.

If this is a one-page type of affair, you could handle the redirect to login with the page as the return_url by using a pre controller.

Thanks for the responses. We have a number of different user groups on the website so I could setup the private page so that all usergroups can access the page. Then I shouldn't end up with a redirect loop, right?

And yes, it is a one-page being private scenario on the website. Can you explain how I would use a pre controller to handle the redirect?

My other (hackish) thought was to edit the contents of the 404 page so that instead it said - sorry the page you are trying to access is not available and embed a login form on the page that had the return_url embedded in it. Not necessarily ideal since it could be a valid 404 issue but I don't think we would as concerned with that and as eComLabs said we should be trying to eliminate any real 404s on the site.

See my updated comment above in #6.

Thanks to you both - eComLab's solution works!

Thank you for keeping us informed!