-
Notifications
You must be signed in to change notification settings - Fork 3.7k
[Feat](Authentication)Supporting Authentication Plugins and Kernel Isolation #41100
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Use a Child-First ClassLoader to isolate plugins from the kernel, giving priority to plugin classes to prevent conflicts between the plugin and kernel classes. Allow users to place plugins in a specified directory, such as auth-lib, to avoid classpath conflicts by default. Support developers in debugging plugins by allowing them to bring in plugins via Maven, making the debugging process more convenient.
|
Thank you for your contribution to Apache Doris. Since 2024-03-18, the Document has been moved to doris-website. |
| private static final Map<String, String> pluginDirMapping = new HashedMap(); | ||
|
|
||
| static { | ||
| pluginDirMapping.put(AuthenticatorFactory.class.getSimpleName(), "auth-lib"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This directory might not be ideal; perhaps we should use plugin/auth instead?
eec5517 to
b6c9474
Compare
|
run buildall |
|
run buildall |
morningman
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
|
PR approved by at least one committer and no changes requested. |
|
PR approved by anyone and no changes requested. |
…er-auth-classloader # Conflicts: # fe/fe-common/src/main/java/org/apache/doris/common/Config.java
|
run buildall |
… loading plugins (#41574) ## Proposed changes in #41100 An exception will be thrown if the user creates the plugin directory but it is empty. When loading plugins, it's acceptable for the plugin directory to be empty. Users might create the directory without placing any plugins inside, but since some plugins are still located on the classpath, this doesn’t cause any issues. If users specify a particular plugin but don’t place it in the directory, the business logic should handle that situation. The general-purpose class shouldn’t be concerned with this.
… loading plugins (apache#41574) ## Proposed changes in apache#41100 An exception will be thrown if the user creates the plugin directory but it is empty. When loading plugins, it's acceptable for the plugin directory to be empty. Users might create the directory without placing any plugins inside, but since some plugins are still located on the classpath, this doesn’t cause any issues. If users specify a particular plugin but don’t place it in the directory, the business logic should handle that situation. The general-purpose class shouldn’t be concerned with this.
… loading plugins (apache#41574) ## Proposed changes in apache#41100 An exception will be thrown if the user creates the plugin directory but it is empty. When loading plugins, it's acceptable for the plugin directory to be empty. Users might create the directory without placing any plugins inside, but since some plugins are still located on the classpath, this doesn’t cause any issues. If users specify a particular plugin but don’t place it in the directory, the business logic should handle that situation. The general-purpose class shouldn’t be concerned with this.
… loading plugins (apache#41574) ## Proposed changes in apache#41100 An exception will be thrown if the user creates the plugin directory but it is empty. When loading plugins, it's acceptable for the plugin directory to be empty. Users might create the directory without placing any plugins inside, but since some plugins are still located on the classpath, this doesn’t cause any issues. If users specify a particular plugin but don’t place it in the directory, the business logic should handle that situation. The general-purpose class shouldn’t be concerned with this.
…olation (apache#41100) ## Proposed changes - Use a Child-First ClassLoader to isolate plugins from the kernel, giving priority to plugin classes to prevent conflicts between the plugin and kernel classes. - Allow users to place plugins in a specified directory, such as auth-lib, to avoid classpath conflicts by default. - Support developers in debugging plugins by allowing them to bring in plugins via Maven, making the debugging process more convenient. (cherry picked from commit c34e86b)
… loading plugins (apache#41574) (apache#209) ## Proposed changes in apache#41100 An exception will be thrown if the user creates the plugin directory but it is empty. When loading plugins, it's acceptable for the plugin directory to be empty. Users might create the directory without placing any plugins inside, but since some plugins are still located on the classpath, this doesn’t cause any issues. If users specify a particular plugin but don’t place it in the directory, the business logic should handle that situation. The general-purpose class shouldn’t be concerned with this. (cherry picked from commit 9b25a83)
…olation (apache#41100) - Use a Child-First ClassLoader to isolate plugins from the kernel, giving priority to plugin classes to prevent conflicts between the plugin and kernel classes. - Allow users to place plugins in a specified directory, such as auth-lib, to avoid classpath conflicts by default. - Support developers in debugging plugins by allowing them to bring in plugins via Maven, making the debugging process more convenient.
…olation (apache#41100) ## Proposed changes - Use a Child-First ClassLoader to isolate plugins from the kernel, giving priority to plugin classes to prevent conflicts between the plugin and kernel classes. - Allow users to place plugins in a specified directory, such as auth-lib, to avoid classpath conflicts by default. - Support developers in debugging plugins by allowing them to bring in plugins via Maven, making the debugging process more convenient. (cherry picked from commit c34e86b)
… loading plugins (apache#41574) ## Proposed changes in apache#41100 An exception will be thrown if the user creates the plugin directory but it is empty. When loading plugins, it's acceptable for the plugin directory to be empty. Users might create the directory without placing any plugins inside, but since some plugins are still located on the classpath, this doesn’t cause any issues. If users specify a particular plugin but don’t place it in the directory, the business logic should handle that situation. The general-purpose class shouldn’t be concerned with this. (cherry picked from commit 9b25a83)
Proposed changes