@R_J said:
This is a configuration error, not a software error. Just because you cannot solve a >problem doesn't mean that no one should use Vanilla and it certainly doesn't mean >Vanilla is not usable at all.
I never said that, I said I am sorry no one better qualified than me has come to help. Because I wish I could help. I am apologizing for those who have know how but are not helping or have no time to do so.
He has been dealing with this issue for weeks now. And is frustrated enough to have said:
At this point Im about to say fuck it and unninstall vanilla forever and move onto another platform but I really dont want because vanilla is all I want and need to integrate with my wordpress site, but its been really frustrating to work with.
When someone threatens to drop vanilla because it is not working for them and they can't get help to resolve it, all one can say is sorry. And advice to use something else. Preferably the paid version of vanilla.
This issue may be that the cookie is not being saved.
Try adding $Configuration['Garden']['WebRoot'] = "http://comp.tf/site/forum/"; to your config.php
It's just a test, I don't really know what to do. Delete the *.ini files in /cache afterwards
Vanilla is installed on the root /forums/ directory but is embedded on the /site/forum page of wordpress.
Vanilla is set up to be redirected/only reachable through /site/forum/, only the dashboard isn't redirected.
On launch Im also planning to have a htaccess rewriterule to rewrite all urls from comp.tf/site/ to comp.tf (the main domain). So the final forum URL would be http://comp.tf/forum/ (the wordpress page, not /forums/ the vanilla installation location)
Not sure any of this has any relevance or might be the cause for this issue.
Nonetheless, I would be ok setting up basic registration even without e-mail confirmation, the problem is, if the Require users to confirm their email addresses (recommended) box is unchecked I get the permission denied error on all users (be it veriefied or not) which is quite strange.
I will toy around with those configurations variables and get back to the thread with more info.
I think you need to test your forum without embedding first and without any plugins enabled, to determine if it is a table, cache, or database or source code glitch, or config problem.
Do you have the problem if the forum is not embedded? test first and try to resolve first.
Also check the permission in the user table for the test user that doesn't work. Blank out the field.
Ideally - what do you want?
do you want email confirmation or not?
Try giving the test user that has a problem - Only one role - member and ensure member role has signin privs after you make the above changes.
Pragmatism is all I have to offer. Avoiding the sidelines and providing centerline pro-tips.
@R_J said:
Try adding $Configuration['Garden']['WebRoot'] = "http://comp.tf/site/forum/"; to your config.php
It's just a test, I don't really know what to do. Delete the *.ini files in /cache afterwards
I think you need to test your forum without embedding first and without any plugins enabled, to determine if it is a table, cache, or database or source code glitch, or config problem.
Do you have the problem if the forum is not embedded? test first and try to resolve first.
Also check the permission in the user table for the test user that doesn't work. Blank out the field.
Ideally - what do you want?
do you want email confirmation or not?
Try giving the test user that has a problem - Only one role - member and ensure member role has signin privs after you make the above changes.
This is definitely weird as hell, kinda driving me crazy hahaha.
Tried with the forum not embedded, all plugins and applications disabled. Still the same issue.
After registering the user it remains logged in, but when I click the link to confirm the email it says the email has been confirmed (while still logged in) and then immediately refreshes and logs out and then I can never log back in and get "Permission denied" over and over again. And yes I triple or quadruple checked, the users only have the member role and it has sign in privilege.
With Require users to confirm their email addresses (recommended) unchecked doesn't work at all either. Just logs off immediately after registering. And there comes "Permission denied" all over again.
Also I just remembered, is it possible this has anything to do with nginx which I think comes out of the box with VestaCP (which my VPS is running)?
@R_J said:
I really cannot imagine what this is. If you give me ftp credentials (with write permissions) I will try to debug it
When you edit the user and check / uncheck the "mail adress confirmed" checkbox, you can literally toggle that permission denied error.
Yes, but then you can't post because you dont have a confirmed email. And as soon as you confirm it, it logs you off.
Also that doesn't work at all if you don't use email confirmation.
I'll pm you ftp details in a bit. Thanks again for your time and willingness to help, it's really strange all this that's happening.
Since he mentioned nginx , maybe the "permissions denied" are in the file system. According to this , you should have an error log further expressing what the error was really about.
CREATE TABLE `GDN_Permission` (
`PermissionID` int(11) NOT NULL AUTO_INCREMENT,
`RoleID` int(11) NOT NULL DEFAULT '0',
`JunctionTable` varchar(100) COLLATE utf8_unicode_ci DEFAULT NULL,
`JunctionColumn` varchar(100) COLLATE utf8_unicode_ci DEFAULT NULL,
`JunctionID` int(11) DEFAULT NULL,
`Garden.Email.View` tinyint(4) NOT NULL DEFAULT '0',
`Garden.Settings.Manage` tinyint(4) NOT NULL DEFAULT '0',
`Garden.Settings.View` tinyint(4) NOT NULL DEFAULT '0',
`Garden.SignIn.Allow` tinyint(4) NOT NULL DEFAULT '0',
`Garden.Users.Add` tinyint(4) NOT NULL DEFAULT '0',
(...)
`Yaga.Ranks.View` tinyint(4) NOT NULL DEFAULT '0',
`1` tinyint(4) NOT NULL DEFAULT '0',
There is a strange column called "1" which messed up your permissions.
I've dropped the complete table, run utility/structure and permissionModel()->resetAllRoles(). Now it is working. Have fun with Vanilla!
@R_J said:
This is a dump of your Permission table.
CREATE TABLE `GDN_Permission` (
`PermissionID` int(11) NOT NULL AUTO_INCREMENT,
`RoleID` int(11) NOT NULL DEFAULT '0',
`JunctionTable` varchar(100) COLLATE utf8_unicode_ci DEFAULT NULL,
`JunctionColumn` varchar(100) COLLATE utf8_unicode_ci DEFAULT NULL,
`JunctionID` int(11) DEFAULT NULL,
`Garden.Email.View` tinyint(4) NOT NULL DEFAULT '0',
`Garden.Settings.Manage` tinyint(4) NOT NULL DEFAULT '0',
`Garden.Settings.View` tinyint(4) NOT NULL DEFAULT '0',
`Garden.SignIn.Allow` tinyint(4) NOT NULL DEFAULT '0',
`Garden.Users.Add` tinyint(4) NOT NULL DEFAULT '0',
(...)
`Yaga.Ranks.View` tinyint(4) NOT NULL DEFAULT '0',
`1` tinyint(4) NOT NULL DEFAULT '0',
There is a strange column called "1" which messed up your permissions.
I've dropped the complete table, run utility/structure and permissionModel()->resetAllRoles(). Now it is working. Have fun with Vanilla!
Wow this is really amazing. I can't thank you enough!
What would be the cause of this strange issue tho since I've reinstalled vanilla from scratch 2 separate times, following all the official instructions and that included reuploading all the core files and deleting the old db and creating a new one from scratch as well, all 3 times I did that and the problem seemed to persist. I couldn't wrap my head around this at all. Is there anything I might be doing wrong in the installation? Or is it any issue with my particular server (I created the dbs through VestaCP but I remember checking them on phpmyadmin and they seemed a clean slate.
I have no idea. You had some more plugins and applications installed on your forum when I've inspected it. If you really like to know who is causing that behavior, you have to do a clean reinstall and than always activate one plugin after the other and all the time create a user and confirm the test users mail address. If this is working without problems, you can activate the next plugin and create a user again.
But you are not using any rarely used plugins, so I'm not sure that this will happen again. After you've made bigger changes, you might want to check the table GDN_Permission and see if there is a column called "1" in there (which should not, but it has been in your db)
@R_J said:
I have no idea. You had some more plugins and applications installed on your forum when I've inspected it. If you really like to know who is causing that behavior, you have to do a clean reinstall and than always activate one plugin after the other and all the time create a user and confirm the test users mail address. If this is working without problems, you can activate the next plugin and create a user again.
But you are not using any rarely used plugins, so I'm not sure that this will happen again. After you've made bigger changes, you might want to check the table GDN_Permission and see if there is a column called "1" in there (which should not, but it has been in your db)
beautiful debugging, very nice R_J
I wonder if the 1 column occurred in the permissions table occurred because of a RegisterPermisions set to TRUE or "FALSE" instead of FALSE without quotes. Either of which potentially might create a 1 column, or if not, there should be a tighter check on column names in the Permissions table to prevent this kind of mishap, which proved to be very time consuming to track down, if the 1 column was the problem.
What I don't understand is if Spacing said they installed from scratch, new database, new source code, without embedding or plugins how they could possibly have Yaga in the permissions table. since Yaga is not part of Vanilla core. That is even more baffling. Or perhaps by scratch they didn't really mean from scratch (new code, no addons, and new database.
Pragmatism is all I have to offer. Avoiding the sidelines and providing centerline pro-tips.
I wonder if the 1 column occurred in the permissions table occurred because of a RegisterPermisions set to TRUE or "FALSE" instead of FALSE without quotes. Either of which potentially might create a 1 column, or if not, there should be a tighter check on column names in the Permissions table to prevent this kind of mishap, which proved to be very time consuming to track down, if the 1 column was the problem.
What I don't understand is if Spacing said they installed from scratch, new database, new source code, without embedding or plugins how they could possibly have Yaga in the permissions table. since Yaga is not part of Vanilla core. That is even more baffling. Or perhaps by scratch they didn't really mean from scratch (new code, no addons, and new database.
I reinstalled everything from scratch at least twice.
The last time I tested without plugins enabled I did indeed reinstall from scratch, everything, including core files and db, but installed plugins as well, and only then disabled them all, so some of them might have created db entries and it is possible one of these plugins was indeed causing this strange issue.
As a note for future reference. Apart from the plugins provided with core here are the ones extra I was using:
Auto Bury - Version 0.1
Bump - Version 1.0
Ignore - Version 1.2.1
Last Edited - Version 1.1.1
Role Titles - Version 1.0
Spoilers - Version 1.3
Yaga - Version 1.1
Afaik all of those were updated to their latest version.
I wonder if the 1 column occurred in the permissions table occurred because of a RegisterPermisions set to TRUE or "FALSE" instead of FALSE without quotes. Either of which potentially might create a 1 column, or if not, there should be a tighter check on column names in the Permissions table to prevent this kind of mishap, which proved to be very time consuming to track down, if the 1 column was the problem.
>
This seemed to be one of your problems in a plugin regarding the extra column in the permissions table that was labeled "1"
What I don't understand is if Spacing said they installed from scratch, new database, new source code, without embedding or plugins how they could possibly have Yaga in the permissions table. since Yaga is not part of Vanilla core. That is even more baffling. Or perhaps by scratch they didn't really mean from scratch (new code, no addons, and new database.
I reinstalled everything from scratch at least twice.
The last time I tested without plugins enabled I did indeed reinstall from scratch, everything, including core files and db, but installed plugins as well, and only then disabled them all, so some of them might have created db entries and it is possible one of these plugins was indeed causing this strange issue.
As a note for future reference. Apart from the plugins provided with core here are the ones extra I was using:
Auto Bury - Version 0.1
Bump - Version 1.0
Ignore - Version 1.2.1
Last Edited - Version 1.1.1
Role Titles - Version 1.0
Spoilers - Version 1.3
Yaga - Version 1.1
Afaik all of those were updated to their latest version.
The problem that was noted dealing with the "strange" column titled "1" in your permissions table is a result of what may be "IMPROPER" usage of 'RegisterPermissions' in the PluginInfo Array of the Auto Bury Plugin. You could delete the line 'RegisterPermissions' => true, and drop the column "1" from your permissions table.
This solves one of your mysteries and problems, it may have not been the root cause of your problem, but it is still something you should correct.
Every time you enable the Auto Bury plugin from the Dashboard you will add an unnecessary column to your permissions table if you do not fix the Auto Bury plugin by removing the line or setting it to false.
$PluginInfo['AutoBury'] = array(
18 'Name' => 'Auto Bury',
19 'Description' => 'Automatically buries comments and discussions, preventing them from being shown.',
20 'Version' => '0.1',
21 'RequiredApplications' => array('Vanilla' => '2.2', 'Yaga' => '1.1'),
22 'MobileFriendly' => true,
23 'HasLocale' => true, 24 'RegisterPermissions' => true, <------------------ IMPROPER USAGE causes permissions table to get an improper "1" column added. </b>
You can see the RegisterPermissions is set to true. The above does not appear to be a valid setting. It should have an actual "name", or the line should be set to false or entirely deleted if you are not "Registering a Permission"
'RegisterPermissions' => true, - Improper usage - DO NOT DO THIS.
'RegisterPermissions' => false , // valid usage , no permissions registered but you could also omit the line.
Adding new permissions via plugin is easy. Any defined here will be added as soon as the plugin is enabled. It's important to know more about using permissions in Vanilla before doing this.
You can provide an array of permission names using dot syntax. You can optionally use key/value pairs to set a default (1 will give all roles the permission; 0 is the default and leaves it off for all roles to start).
'RegisterPermissions' => array('FancyPlugin.DoStuff.Add' => 1),
Or set the default to whether or not the role currently has an existing permission:
'RegisterPermissions' => array('FancyPlugin.DoStuff.Add' => 'Garden.Settings.Manage`),
This allows you to set good defaults while allowing them to be changed independently in the future._
The vanilla core code could be modified to be more strict in preventing improper columns from being added to the the permissions table by checking the RegisterPermissions and throwing out invalid names. A Boolean true for registerpermissions ideally should not add a "1" column table when being enabled. Something for someone to further investigate and fix to prevent other plugins from causing problems, and ideally the Auto Bury plugin should be fixed as well.
I don't know if you have a copy of your permissions table that caused your signin problem, however it would be interesting to compare with a valid table that doesn't compare to see what setting actually caused your problem, or if the 1 column caused a cascade affect or was just an innocent bystander due to improper usage.
Pragmatism is all I have to offer. Avoiding the sidelines and providing centerline pro-tips.
@River: really great that you've inspected all the possible reasons for that! I think you should file an issue on GitHub concerning that danger. I agree that there should be some kind of check so that things like that wouldn't happen.
@hgtonight will be interested in this, too, so that he can correct his plugin.
Comments
Could you post the config values of the config names I've posted above?
On config.php only found this one
On config-defaults.php
is there a cookie salt like this ?
$Configuration['Garden']['Cookie']['Salt'] = 'XYZ1Z5CC81';❌ ✊ ♥. ¸. ••. ¸♥¸. ••. ¸♥ ✊ ❌
I never said that, I said I am sorry no one better qualified than me has come to help. Because I wish I could help. I am apologizing for those who have know how but are not helping or have no time to do so.
He has been dealing with this issue for weeks now. And is frustrated enough to have said:
When someone threatens to drop vanilla because it is not working for them and they can't get help to resolve it, all one can say is sorry. And advice to use something else. Preferably the paid version of vanilla.
This issue may be that the cookie is not being saved.
❌ ✊ ♥. ¸. ••. ¸♥¸. ••. ¸♥ ✊ ❌
Yes, there is a cookie salt, a bit longer than that one.
Try adding
$Configuration['Garden']['WebRoot'] = "http://comp.tf/site/forum/";to your config.phpIt's just a test, I don't really know what to do. Delete the *.ini files in /cache afterwards
I think you need to test your forum without embedding first and without any plugins enabled, to determine if it is a table, cache, or database or source code glitch, or config problem.
Do you have the problem if the forum is not embedded? test first and try to resolve first.
Also check the permission in the user table for the test user that doesn't work. Blank out the field.
Ideally - what do you want?
do you want email confirmation or not?
Try giving the test user that has a problem - Only one role - member and ensure member role has signin privs after you make the above changes.
Pragmatism is all I have to offer. Avoiding the sidelines and providing centerline pro-tips.
since you are testing things out.
You might try a test install of vanilla 2.3b1 unembedded and see if the problems still occur.
Pragmatism is all I have to offer. Avoiding the sidelines and providing centerline pro-tips.
Tried this. Didn't work.
This is definitely weird as hell, kinda driving me crazy hahaha.
Tried with the forum not embedded, all plugins and applications disabled. Still the same issue.
After registering the user it remains logged in, but when I click the link to confirm the email it says the email has been confirmed (while still logged in) and then immediately refreshes and logs out and then I can never log back in and get "Permission denied" over and over again. And yes I triple or quadruple checked, the users only have the member role and it has sign in privilege.
With
Require users to confirm their email addresses (recommended)unchecked doesn't work at all either. Just logs off immediately after registering. And there comes "Permission denied" all over again.Also I just remembered, is it possible this has anything to do with nginx which I think comes out of the box with VestaCP (which my VPS is running)?
I really cannot imagine what this is. If you give me ftp credentials (with write permissions) I will try to debug it
When you edit the user and check / uncheck the "mail adress confirmed" checkbox, you can literally toggle that permission denied error.
Yes, but then you can't post because you dont have a confirmed email. And as soon as you confirm it, it logs you off.
Also that doesn't work at all if you don't use email confirmation.
I'll pm you ftp details in a bit. Thanks again for your time and willingness to help, it's really strange all this that's happening.
I've found not much until now, only that permissions seems to be borked:
unconfirmed perms: Array ( [0] => Garden.Email.View [1] => Array ( [0] => -1 ) [2] => Garden.Activity.View [3] => Garden.Profiles.View [4] => Yaga.Reactions.View [5] => Yaga.Badges.View [6] => Yaga.Ranks.View [7] => 1 [Vanilla.Discussions.View] => Array ( [0] => -1 ) ) user perms: Array ( [0] => Garden.Email.View [1] => Garden.SignIn.Allow [2] => Garden.Activity.View [3] => Garden.Profiles.View [4] => Vanilla.Discussions.View [5] => Yaga.Reactions.View [6] => Yaga.Badges.View [7] => Yaga.Ranks.View [Vanilla.Discussions.View] => Array ( [0] => -1 ) )Later on I'll take a look on your permission table, but the way this looks, I'd say there is a problem in a model
Since he mentioned nginx , maybe the "permissions denied" are in the file system. According to this , you should have an error log further expressing what the error was really about.
https://www.scalescale.com/tips/nginx/13-permission-denied-while-reading-upstream-using-nginx/#stq=&stp=0
Maybe it is your server configuration after all. I hope some of this can help. At least you can see how to generate an error log.
❌ ✊ ♥. ¸. ••. ¸♥¸. ••. ¸♥ ✊ ❌
This is a dump of your Permission table.
There is a strange column called "1" which messed up your permissions.
I've dropped the complete table, run utility/structure and permissionModel()->resetAllRoles(). Now it is working. Have fun with Vanilla!
Wow this is really amazing. I can't thank you enough!
What would be the cause of this strange issue tho since I've reinstalled vanilla from scratch 2 separate times, following all the official instructions and that included reuploading all the core files and deleting the old db and creating a new one from scratch as well, all 3 times I did that and the problem seemed to persist. I couldn't wrap my head around this at all. Is there anything I might be doing wrong in the installation? Or is it any issue with my particular server (I created the dbs through VestaCP but I remember checking them on phpmyadmin and they seemed a clean slate.
I have no idea. You had some more plugins and applications installed on your forum when I've inspected it. If you really like to know who is causing that behavior, you have to do a clean reinstall and than always activate one plugin after the other and all the time create a user and confirm the test users mail address. If this is working without problems, you can activate the next plugin and create a user again.
But you are not using any rarely used plugins, so I'm not sure that this will happen again. After you've made bigger changes, you might want to check the table GDN_Permission and see if there is a column called "1" in there (which should not, but it has been in your db)
beautiful debugging, very nice R_J
I wonder if the 1 column occurred in the permissions table occurred because of a RegisterPermisions set to TRUE or "FALSE" instead of FALSE without quotes. Either of which potentially might create a 1 column, or if not, there should be a tighter check on column names in the Permissions table to prevent this kind of mishap, which proved to be very time consuming to track down, if the 1 column was the problem.
What I don't understand is if Spacing said they installed from scratch, new database, new source code, without embedding or plugins how they could possibly have Yaga in the permissions table. since Yaga is not part of Vanilla core. That is even more baffling. Or perhaps by scratch they didn't really mean from scratch (new code, no addons, and new database.
Pragmatism is all I have to offer. Avoiding the sidelines and providing centerline pro-tips.
I reinstalled everything from scratch at least twice.
The last time I tested without plugins enabled I did indeed reinstall from scratch, everything, including core files and db, but installed plugins as well, and only then disabled them all, so some of them might have created db entries and it is possible one of these plugins was indeed causing this strange issue.
As a note for future reference. Apart from the plugins provided with core here are the ones extra I was using:
Afaik all of those were updated to their latest version.
This seemed to be one of your problems in a plugin regarding the extra column in the permissions table that was labeled "1"
The problem that was noted dealing with the "strange" column titled "1" in your permissions table is a result of what may be "IMPROPER" usage of 'RegisterPermissions' in the PluginInfo Array of the Auto Bury Plugin. You could delete the line 'RegisterPermissions' => true, and drop the column "1" from your permissions table.
This solves one of your mysteries and problems, it may have not been the root cause of your problem, but it is still something you should correct.
Every time you enable the Auto Bury plugin from the Dashboard you will add an unnecessary column to your permissions table if you do not fix the Auto Bury plugin by removing the line or setting it to false.
$PluginInfo['AutoBury'] = array(
18 'Name' => 'Auto Bury',
19 'Description' => 'Automatically buries comments and discussions, preventing them from being shown.',
20 'Version' => '0.1',
21 'RequiredApplications' => array('Vanilla' => '2.2', 'Yaga' => '1.1'),
22 'MobileFriendly' => true,
23 'HasLocale' => true,
24 'RegisterPermissions' => true, <------------------ IMPROPER USAGE causes permissions table to get an improper "1" column added. </b>
You can see the RegisterPermissions is set to true. The above does not appear to be a valid setting. It should have an actual "name", or the line should be set to false or entirely deleted if you are not "Registering a Permission"
'RegisterPermissions' => true, - Improper usage - DO NOT DO THIS.
'RegisterPermissions' => false , // valid usage , no permissions registered but you could also omit the line.
the documentation states this: http://docs.vanillaforums.com/developers/plugins/quickstart/
The vanilla core code could be modified to be more strict in preventing improper columns from being added to the the permissions table by checking the RegisterPermissions and throwing out invalid names. A Boolean true for registerpermissions ideally should not add a "1" column table when being enabled. Something for someone to further investigate and fix to prevent other plugins from causing problems, and ideally the Auto Bury plugin should be fixed as well.
I don't know if you have a copy of your permissions table that caused your signin problem, however it would be interesting to compare with a valid table that doesn't compare to see what setting actually caused your problem, or if the 1 column caused a cascade affect or was just an innocent bystander due to improper usage.
Pragmatism is all I have to offer. Avoiding the sidelines and providing centerline pro-tips.
@River: really great that you've inspected all the possible reasons for that! I think you should file an issue on GitHub concerning that danger. I agree that there should be some kind of check so that things like that wouldn't happen.
@hgtonight will be interested in this, too, so that he can correct his plugin.