I reached CH 11 in this so valuable book. My question is:
Using the routing system applied in the book case study, how to prevent users from directly accessing pages like ‘login/success’, ‘author/logout’ and ‘author/register/success’ when they try to access them using direct URLs in the browser bar?
I managed to solve a problem that when a user uses a mistyped URL like (for example): ‘joke/listx’ or ‘foke/list’, which, without a way to handle it, causes PHP to throw lines of undefined indexes errors.
But I didn’t work out a way to handle the other problem mentioned first. Thank you, the authors for the incomparable book. Thank to the community here and to the Sitepoint. Help will be really appreciated.
This is done by the Authentication class, which is then used in the Routes class by adding the getAuthentication method, then a check in EntryPoint.php, all explained in the chapter. Has this been added?
What specific problem are you having with it?
Ping @TomB
Thank you for the response.
Yes, getAuthentication() is added. But the problem is not about authentication.
The problem is that these templates are supposed to be sent to the browser as a result of an internal diecision then a redirection with header(), not to be directly accessible via a user typed URL. So for example, I (or any user) can type: ‘myapp/login/success’ any time in the browser bar and get the template that shows ‘You are logged in’, even if I am not actually logged in. Or ‘myapp/register/success’ and get the template ‘Registration successful’ even if I am logged in or even not registered or logged in at all.
If you follow the rest of the book through, you add a login key to the routes array which is used to flag which pages can only be viewed when you’re logged in.
Thank you so much @TomB. As I said I haven’t finished the book yet. Yes that makes it easy for me to continue studying and following the steps to the end. I learned a lot from your book. Thank you so much for it.
Thank you @SamA74.
@TomB… I realized now what you meant. If you mean ‘login’ => true, then thats not what I am asking about. Please read my reply to @SamA74 again. Thank you.
I’m not sure I understand your question. If you want to make it so pages are only visible to users who are logged in, add the 'login' => true key to the $routes array. If you want to make it so only logged in users can see the myapp/login/success page, add the login check to it.
Sorry @TomB, but I do not mean those pages should only be visible to logged in users.
You know there are some HTML templates, like registersuccess.html.php, that are supposed to be sent to browser via header() redirect only when a successful registration is made. These template shouldn’t be accessible by typing their URLs in the browser bar. But they are accessible though! I can access registersuccess.html.php while I am logged in or not logged in, and even before I register. Any user can see 'Registration successful just by typing …/register/success in the browser!
loginsuccess.html.php and loginerror.html.php can be accessed through their routes without being a result of redirect. Is that what should normally be expected!
That’s correct. You could add a session variable when someone registers and then check it exists on the register success page but the benefit is negligible. Does it matter if someone can go directly to the URL and see that page? It doesn’t display any sensitive information or have any negative effect at all if someone can visit it.
You could also skip the header redirect and just display the success message after a successful registration. However, as noted in the book, a header redirect stops people from submitting the form multiple times.
I think it is just nonprofessional. It dosen’t get along with the solid approach used in the book and the best practices the book teaches.
I will see how the session variable solution can be applied, even though I don’t see it is applicable in the other contexts like You are not logged in page that can be accessed even when the user is logged in.
These pages must exist on the server somewhere and be accessible to view. If you really want you can add additional checks using session variables you can but it is additional code for no practical benefit. If someone accesses a page by typing in the URL and being in the incorrect state, they should not expect a meaningful page. As long as no sensitive information is leaked on these pages, and people can’t see/do things they shouldn’t be able to, having this page accessible via its URL really makes no difference, especially when it’s a generic error message.
I just always try to see if such flaws could be found in websites I visit and like, and I dont find. Yes, there’s no practical problem, but practical problems, though the first and top concern, are not the only problems a good design should strive to a void.