Skip to content
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

Multiple JMX Credentials for a target JVM with the same target alias #474

Closed
maxcao13 opened this issue Jun 28, 2022 · 4 comments · Fixed by #475
Closed

Multiple JMX Credentials for a target JVM with the same target alias #474

maxcao13 opened this issue Jun 28, 2022 · 4 comments · Fixed by #475
Labels
question Further information is requested

Comments

@maxcao13
Copy link
Member

Wondering, is it intended for the deletion of a JMX Credentials to delete all credentials for the same target?

If I also navigate away, it will also delete extra credentials of the same target, leaving only 1 of them regardless if the actual username and password were different or not.

@maxcao13 maxcao13 added the question Further information is requested label Jun 28, 2022
@andrewazores
Copy link
Member

You're only meant to be able to store 0 or 1 sets of credentials for a target. The targetId is used as a unique key for this, like we have done elsewhere, so if you have "aliased targets" where more than one targetId's JMX URL points to the same actual JVM instance, then you can do weird things. Though in that case, the credentials used will simply depend on which URL you use to access the target JVM.

It sounds like you're describing a graphical bug where the table displays more than one row for a given JVM target?

@maxcao13
Copy link
Member Author

Right, I think the UI should just not let you create more than 1 set of credentials for each target then, because people are able to do that right now, not that it really affects anything other than, like you said a graphical bug.

@andrewazores
Copy link
Member

I believe it'll end up overwriting the previous credentials on the backend when you do that, which I think makes sense. But the table is supposed to remove the previous entry and replace it with the new one when you do that. Sounds like that's been broken, but #465 will happen to fix this bug anyway since the table is getting redone.

@maxcao13
Copy link
Member Author

Gotcha, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants