Comments (6)
Currently, hawtio-oauth is a dependency of hawtio-console-assembly and it makes sense, doesn't it?
Apps that use oauth can depend on hawtio-oauth.
I personally think ConnectOptions shouldn't have the username, password, and token fields. They should be in a different object.
When we open a new window, the username and password are passed to the new window via properties in the parent window. What do you think of this strategy?
from hawtio-jmx.
Currently, hawtio-oauth is a dependency of hawtio-console-assembly and it makes sense, doesn't it?
Apps that use oauth can depend on hawtio-oauth.
For sure, but the question is: as all the apps that depends on hawtio-integration depends on hawtio-oauth, would that make sense to have hawtio-jmx depends on hawtio-oauth to avoid duplications, inconsistencies and enables removing use of ConnectOptions.token
?
When we open a new window, the username and password are passed to the new window via properties in the parent window. What do you think of this strategy?
What about page reload? Original question is about ConnectOptions.token
but we can discuss username and password in a subsequent point.
from hawtio-jmx.
from hawtio-jmx.
I'm not against it. If you guys feel it's a better place to define the
dependency, than do it. We just need to make sure it doesn't cause any
issues to apps that don't use oauth.
Hence my question ;) I'm requesting feedback.
That's currently an issue because we aren't storing the credentials in any
persistent storage and I guess we can't access the parent window after a
page reload. Session storage could be a good place to temporarily store the
credentials but storing a password as plain text isn't awesome isn't it?
Hence the original question discussing token not username / password.
from hawtio-jmx.
Hi guys,
as all the apps that depends on hawtio-integration depends on hawtio-oauth, would that make sense to have hawtio-integration depends on hawtio-oauth to avoid duplications and inconsistencies?
Honestly, I'd feel against the idea of hawtio-jmx depending on hawtio-oauth. Logically speaking, how to authenticate the app (= hawtio-oauth) is orthogonal to what functionalities it provides (= hawtio-jmx & hawtio-integration). To me it is quite straightforward that the assembling projects combine hawtio-oauth and hawtio-jmx & hawtio-integration.
Recently I've made these changes cbe1d29 & hawtio/hawtio-oauth@1fb0eaa so that hawtio-oauth can overwrite the Ajax beforeSend
to attach Keycloak token to each request to Jolokia. I think it's more beautiful to keep the getBeforeSend()
code in hawtio-jmx as simple as possible and have hawtio-oauth (or other plugins) overwrite/extend it with their specific needs. @astefanutti Can it not be a solution to your problem?
Actually in the OpenShift console, the user stays in the same window and in hawtio-online the token is passed in the URL hash. So we may use the session store instead of the local store.
Considering the use cases of hawtio-oauth on OpenShift it seems acceptable to store the token to local storage, but then please make sure to clean it up upon logout through pre/postLogoutTasks
just like:
https://github.com/hawtio/hawtio-integration/blob/master/plugins/activemq/ts/activemqPlugin.ts#L62-L67
from hawtio-jmx.
@tadayosi thanks a lot, that helps!
Honestly, I'd feel against the idea of hawtio-jmx depending on hawtio-oauth. Logically speaking, how to authenticate the app (= hawtio-oauth) is orthogonal to what functionalities it provides (= hawtio-jmx & hawtio-integration). To me it is quite straightforward that the assembling projects combine hawtio-oauth and hawtio-jmx & hawtio-integration.
I agree. For the time being, hawtio-integration is used as an application in itself in the hawtio-online image. While that's convenient by avoiding creating a dedicated layer / project for it, I guess it will need to diverge any time soon. So I'll create that dedicated layer, similar to https://github.com/hawtio/openshift-jvm, and that will be symmetrical with Hawtio 2.x too.
Recently I've made these changes cbe1d29 & hawtio/hawtio-oauth@1fb0eaa so that hawtio-oauth can overwrite the Ajax beforeSend to attach Keycloak token to each request to Jolokia. I think it's more beautiful to keep the getBeforeSend() code in hawtio-jmx as simple as possible and have hawtio-oauth (or other plugins) overwrite/extend it with their specific needs. @astefanutti Can it not be a solution to your problem?
Yes, if I create that openshift-jvm thing, then it will have hawtio-oauth and that will work.
Actually in the OpenShift console, the user stays in the same window and in hawtio-online the token is passed in the URL hash. So we may use the session store instead of the local store.
Considering the use cases of hawtio-oauth on OpenShift it seems acceptable to store the token to local storage, but then please make sure to clean it up upon logout through pre/postLogoutTasks just like:
https://github.com/hawtio/hawtio-integration/blob/master/plugins/activemq/ts/activemqPlugin.ts#L62-L67
Agree, I think that's what the logout()
method does in hawtio-oauth already.
Let me close this and I'll implement the above in hawtio-online. Thanks again!
from hawtio-jmx.
Related Issues (20)
- Improve Diagnostics UI HOT 15
- Various shortcomings in jvm/connect compared to 1.x
- Diagnostics - Class Histogram: use pfTableView with toolbar HOT 1
- Diagnostics - Hotspot Diagnostics: use pfTableView with toolbar HOT 2
- Connect plugin - Update Instructions HOT 6
- More intuitive feedback on connecting to other JVM HOT 2
- Refactor jolokiaService.ts into multiple files
- Error callback is always ignored in JolokiaService HOT 3
- Set up unit testing with Karma, Jasmine, and CircleCI 2.0 HOT 1
- Connect options token is not used anymore HOT 5
- Log entry modal dialog displays HTML encoded data for message field
- Move hawtio-log to hawtio-jmx
- Replace remote connection login dialog box with a full page HOT 6
- Connection details dialog allows duplicate names
- Log - Filtering doesn't seem to work
- Connect: move Remote instructions to popover
- Sort diagnostics class histogram table by bytes column
- Spring Boot runtime metrics card remains in loading state
- Move code to hawtio-integration HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from hawtio-jmx.