![](https://seccdn.libravatar.org/avatar/008a8db3f6a813af5f8064f2be96e100.jpg?s=120&d=mm&r=g)
Thanks for this update, Per. A couple comments inline below: On Mon, 02 Mar 2020 13:26:14 +0100, Per Jessen wrote:
- I am not yet able to actually run the vBulletin code - currently I get an HTTP 500, which I'm still trying to figure out.
Looking at the error message, I think Gertjan is on track - this is coming from vBulletin 5. I know we talked about the database needing to be upgraded, and that was the plan - but to confirm, did you install the database on version 4 first and then upgrade to version 5?
- authentication. The 'vb_user' table holds 40501 rows. The current system is tied in to the SSO setup in Provo, I don't know how or if this table is used.
The way it works (as I understand it) is that the SSO process sends over data to vBulletin so it can provision the records in the database. vBulletin itself doesn't know about the external authority, so each of those rows of data is a valid user. The passwords that are stored are bogus (as the password exchange takes place over the SSO connection). I don't have a lot of insight into how the SSO process actually works (my testing environment isn't set up for SSO), but typically you need some metadata on your end, and the identity provider (where the user logs in) needs to know a callback URL so it knows where to go after the login is completed. If the callback URL isn't configured properly, SSO won't work - Jared will need to make changes in the MF SSO setup in order to make this work as things stand right now - even suse.com (as of a week ago, at least) still redirects to the MicroFocus login page for authentication. If we opt to not be SSO-enabled, every user is going to need to reset their password manually, and the users will be subject to any security flaws in the vBulletin PHP code (we've had a couple of incidents over the years, but haven't been affected because the vb_user table doesn't store real passwords for anyone other than staff - those passwords are used to access the admin and moderator interfaces). Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: heroes+unsubscribe@opensuse.org To contact the owner, e-mail: heroes+owner@opensuse.org