One of the plugin users raised questions about the plugin security and I answered them in separate comments. I wanted to put these aspects all together in one place.
- First, the plugin conforms to Vanilla permissions model - whatever parameters are used to display the discussions, they augment the Vanilla built-in permission model. For example, if a user does not have access to a category, no matter which filter is used the users won't see discussions in the unauthorized category.
- To use the plugin the user must have a special permission ('Plugins.FilterDiscussion.View') set in Roles. Since an admin is authorized for everything an admin may not notice that regular users cannot get results unless they are also granted that permission.
- The plugin dashboard defined which columns can be used for filtering so if you have additional columns (for example those defined by the Discussion Extender plugin) they can be disallowed to be used for filtering.
- Filter specifications can be saved as named filters hiding the parameters from end users.
Hope that answers some questions.
As many of of you might have noted, the 2.8 release is around the corner. https://open.vanillaforums.com/discussion/36959/more-changes-in-vanilla-2-8-coming-feb-6#latest
There are a few things I'd like to note for addon developers in this release.
Note on new classes
We've added quite a few new subsystems that are not fully ready for public consumption. I'm trying to mark them with the
@internal annotation, but I may not get all of them. With that in mind:
Don't use new undocumented classes, especially ones with the
@internal annotation, unless you are ready and prepared to update them in the next release. We are actively iterating on these new parts of the framework, and some may have their public APIs, and classnames adjusted in the next release.
A few examples of of classes or namespaces like this.
When these new pieces are completed we will document them publicly, deprecate old alternatives, and provide a clear path forward. Thank you for your understanding.
I'm trying to set up a page (let's call it example.com) with embedded Vanilla comments. The idea is that when a user logs in to example.com they are also logged in to Vanilla via OIDC SSO.
A user can already log in to example.com using OIDC. During the log in process to example.com the auth provider gives all of its SSO targets an SSO token using an HTTPS GET call, e.g. vanilla.example.com?sso_token=abcd1234. The SSO targets should at this point store the SSO token e.g. to a cookie and later append it and another query parameter (prompt=none) to the authorization url to log in to the application silently without additional user interaction.
Are there any plugins that already implement this flow? I'm currently using the OAuth2 plugin, but it does not seem to support this use case.