Invision Community 4: SEO, prepare for v5 and dormant account notifications By Matt Monday at 02:04 PM
Daniel F Posted February 8, 2023 Posted February 8, 2023 I'm not sure why, but recently the number of submissions with some issues related to guests and handling them increased a lot recently. Sometimes it's harmless, like showing some content and using \IPS\Member::loggedIn()->member_id in the where condition, but sometimes it's really dangerous because either you're allowing an attacker/or just random visitor to delete all the guest accounts,to spam the board as guest, to flood peoples member table with hundreds of guest accounts and and and... There are dozen of bad scenarios which I've seen in the last months. So, when working with the visitor object ( Member::loggedIn() ) in controllers, ask yourself=> Should this controller be accessed by guests at all? If not, just put the following code in the controllers' execute method to block guests. /* Logged in?*/ if ( !\IPS\Member::loggedIn()->member_id ) { \IPS\Output::i()->error( 'no_module_permission', '2....', 403, '' ); } If it's only related to specific actions, call it in the specific actions! Never trust that a controller or method won't be called by somebody, just because the navbar link is visible to only logged in members:) Also when you want to change something for the currently logged in member, don't expect that he's logged in! You really should make sure that the member is logged in and not a guest before you start to change some properties and use the save method to store the changes, otherwise you'll save the guest instance in the members table, which will look like this which in 99.9999% isn't what you want & need;) Afrodude, Kirill Gromov and IPCommerceFan 3
Kirill Gromov Posted February 8, 2023 Posted February 8, 2023 I fell into this trap, it's really not easy to think about the guest every time, thanks! Afrodude 1
Recommended Posts