<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I agree that some of this data might not fit in standalone.xml or domain.xml, <div class="">but I'd like to get away from storing all kind of HAL related settings and data </div><div class="">in the browser local storage. </div><div class=""><br class=""></div><div class="">In the meantime there's another RFE coming up to customise the browser </div><div class="">title for the console. </div><div class=""><br class=""></div><div class="">What I'm looking for is an way to store these kind of data in the management </div><div class="">model in a way that is extendable and future proof. </div><div class=""><br class=""></div><div class="">I don't have any cloud specific use cases in mind, but I suppose that having a</div><div class="">place for HAL to store settings will also be a plus for HAL running in an OpenShift</div><div class="">environment. </div><div class=""><br class=""></div><div class="">I mentioned RBAC, because I'd like to protect macros which is not possible atm.</div><div class="">Macros should only be visible and executable for specific roles.</div><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 4. Apr 2019, at 23:17, Brian Stansberry <<a href="mailto:brian.stansberry@redhat.com" class="">brian.stansberry@redhat.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><div dir="ltr" class=""><div class="gmail_default" style="font-family: "trebuchet ms", sans-serif;">I can't see storing this kind of thing in standalone.xml or host.xml, so this means some other form of persistent store. The use cases around managing that store would have to be gone through carefully.</div><div class="gmail_default" style="font-family: "trebuchet ms", sans-serif;"><br class=""></div><div class="gmail_default" style="font-family: "trebuchet ms", sans-serif;">The content repository can be used for that kind of thing, but it's not meant to be directly managed. So no supported copying of your content from one instance to another, etc, at least not without specific tooling we'd have to provide. </div><div class="gmail_default" style="font-family: "trebuchet ms", sans-serif;"><div class="gmail_default"><br class=""></div><div class="gmail_default">People would also expect to be able to migrate this content when upgrading. Which is just a variant of copying your content from one instance to another.</div><br class="gmail-Apple-interchange-newline"></div><div class="gmail_default" style="font-family: "trebuchet ms", sans-serif;">For a domain the content repository is a domain-wide store (which is actually a pro, since it means any host that is in sync with the domain can become master and know it will have the needed data.)</div><div class="gmail_default" style="font-family: "trebuchet ms", sans-serif;"><br class=""></div><div class="gmail_default" style="font-family: "trebuchet ms", sans-serif;">How would this relate to possible uses of HAL in cloud environments?</div></div></div></div></blockquote><blockquote type="cite" class=""><div class=""><div dir="ltr" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 4, 2019 at 6:05 AM Harald Pehl <<a href="mailto:hpehl@redhat.com" class="">hpehl@redhat.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;">The management console uses various settings which need to survive a browser<span class="Apple-converted-space"> </span><br class="">restart. Currently these settings are stored client side only either as cookie or<span class="Apple-converted-space"> </span><br class="">in the browser local storage:<br class=""><br class=""># Cookie<br class=""><br class="">- Google Analytics on/off<br class="">- Page size<br class="">- Poll on/off<br class="">- Poll time<br class=""><br class=""># Local Storage<br class=""><br class="">- Management endpoints (for HAL standalone mode)<br class="">- Pinned items in the finder<br class="">- JavaScript extensions<br class="">- Macros<br class=""><br class="">Using the browser to store settings has the advantage of being very flexible.<span class="Apple-converted-space"> </span><br class="">The settings are also not bound to a specific WildFly instance. For some<span class="Apple-converted-space"> </span><br class="">settings like the management endpoints this is a requirement and won't change.<span class="Apple-converted-space"> </span><br class=""><br class="">However other settings make more sense if they are stored on the server side.<span class="Apple-converted-space"> </span><br class="">That's why I'd like to propose a dedicated subsystem for HAL. It should hold<span class="Apple-converted-space"> </span><br class="">the current settings (except the management endpoints). It should be extendable<br class="">to store additional settings (currently there's an RFE to customize the<span class="Apple-converted-space"> </span><br class="">visibility of notifications in HAL).<span class="Apple-converted-space"> </span><br class=""><br class="">Another advantage is that settings and data like macros could be properly<span class="Apple-converted-space"> </span><br class="">secured using RBAC.<span class="Apple-converted-space"> </span><br class=""></blockquote><div class=""><br class=""></div><div class="gmail_default" style="font-family: "trebuchet ms", sans-serif;">How so?</div><div class="gmail_default" style="font-family: "trebuchet ms", sans-serif;"><br class=""></div><div class="gmail_default" style="font-family: "trebuchet ms", sans-serif;">I assume content would be per user so access to parts of the content would be restricted based on userid.</div><div class="gmail_default" style="font-family: "trebuchet ms", sans-serif;"><br class=""></div><div class="gmail_default" style="font-family: "trebuchet ms", sans-serif;">Perhaps some kind of administrative operations that give access to other users content, use of which would be limited based on the WildFly RBAC roles?</div><div class="gmail_default" style="font-family: "trebuchet ms", sans-serif;"></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><br class="">I would like to hear your opinion about a dedicated subsystem for HAL.<span class="Apple-converted-space"> </span><br class="">Does it makes sense? How should it look like? Any feedback and comments are<span class="Apple-converted-space"> </span><br class="">welcome!<br class=""><br class="">// Harald<br class="">_______________________________________________<br class="">wildfly-dev mailing list<br class=""><a href="mailto:wildfly-dev@lists.jboss.org" target="_blank" class="">wildfly-dev@lists.jboss.org</a><br class=""><a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank" class="">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br class=""></blockquote></div><br clear="all" class=""><div class=""><br class=""></div>--<span class="Apple-converted-space"> </span><br class=""><div dir="ltr" class="gmail_signature"><div dir="ltr" class="">Brian Stansberry<div class="">Manager, Senior Principal Software Engineer</div><div class="">Red Hat</div></div></div></div></div></blockquote></div><br class=""></div></body></html>