Proposal to make webui-vue the standard

Proposal to make webui-vue the standard

[Gunnar Mills]

[-- Attachment #1: Type: text/plain, Size: 3057 bytes --]

Hi All,

From some continued discussion yesterday in the GUI Design Workgroup, we 
would like to see the community move away from phosphor-webuiand for 
webui-vueto become the standard. All companies on the call were in favor 
of this but I’ll let them chime in for themselves.

As stated in previous emails there are many benefits to the webui-vueGUI.
webui-vueadds:

  * Improved user experience based on feedback from OpenBMC users
  * Conformance with the W3C Web Content Accessibility Guidelines 2.1
    specification
  * Ability to easily theme to meet brand guidelines
  * Dynamically generate navigation
  * Language translation-ready
  * Full Redfish
  * Modern front-end framework with an active community and future
    development roadmap

The phosphor-webuifront-end framework, AngularJS, will sunset in June of 
2021. Based on this, the most active contributing companies have moved 
to webui-vueresulting in a decrease of development activity on 
phosphor-webuiover the past six months.
We also believe webui-vueallows us to move forward other areas, for 
example, turning off exposing the D-Bus interfaces as a REST API. This 
change would break phosphor-webui. Since webui-vueuses Redfish this is 
not the case for it. 
https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/29344 
<https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/29344>
As requested, below is an updated timeline:
With Virtual Media merged, 8 identified issues to reach parity:
https://github.com/openbmc/webui-vue/issues?q=is%3Aissue+is%3Aopen+label%3Aphosphor-webui-feature-parity 
<https://github.com/openbmc/webui-vue/issues?q=is%3Aissue+is%3Aopen+label%3Aphosphor-webui-feature-parity>
IBM plans to work on, with an estimated completion of mid-October:

  * Two file Firmware upload (#9)
  * Loading webui-vue from the BMC causes content-security-policy errors
    (#32)
  * Radio button for DHCP - Network settings (#36)

And will work on when the Redfish interfaces for these are implemented:

  * Remote Logging (#34)
  * SNMP (#33)

The last 2 identified issues, we are looking for community help but 
might take these up ourselves one day:

  * Mutual TLS (#30)
  * CSRF allow list (#29)

The last issue, Next URL forward (#28) has a review up.  Thanks Mateusz!

Please let us know if we have missed any features needed to reach parity 
with phosphor-webui.

Would any of these outstanding issues keep the community from accepting 
webui-vueas the standard?

Not sure officially making webui-vuethe standard means a lot, we plan to 
update docs/ links to point at webui-vueandview as the first step 
towards eventually deprecating / archiving phosphor-webui.

Is there any objection to this?

Some previous discussion on these topics here:
https://lists.ozlabs.org/pipermail/openbmc/2020-August/022637.html 
<https://lists.ozlabs.org/pipermail/openbmc/2020-August/022637.html>
https://lists.ozlabs.org/pipermail/openbmc/2020-February/020491.html 
<https://lists.ozlabs.org/pipermail/openbmc/2020-February/020491.html>

Thanks,
Derick, Gunnar, and Yoshie

[-- Attachment #2: Type: text/html, Size: 33241 bytes --]

Re: Proposal to make webui-vue the standard

[Bills, Jason M]

On 9/18/2020 9:31 AM, Gunnar Mills wrote:
> Hi All,
> 
> From some continued discussion yesterday in the GUI Design Workgroup, we 
> would like to see the community move away from phosphor-webuiand for 
> webui-vueto become the standard. All companies on the call were in favor 
> of this but I’ll let them chime in for themselves.

 From Intel, we use a custom fork of phosphor-webui for our current 
platforms.  We plan to abandon this fork and move to webui-vue for our 
future platforms.  Thanks!

> 
> As stated in previous emails there are many benefits to the webui-vueGUI.
> webui-vueadds:
> 
>   * Improved user experience based on feedback from OpenBMC users
>   * Conformance with the W3C Web Content Accessibility Guidelines 2.1
>     specification
>   * Ability to easily theme to meet brand guidelines
>   * Dynamically generate navigation
>   * Language translation-ready
>   * Full Redfish
>   * Modern front-end framework with an active community and future
>     development roadmap
> 
> The phosphor-webuifront-end framework, AngularJS, will sunset in June of 
> 2021. Based on this, the most active contributing companies have moved 
> to webui-vueresulting in a decrease of development activity on 
> phosphor-webuiover the past six months.
> We also believe webui-vueallows us to move forward other areas, for 
> example, turning off exposing the D-Bus interfaces as a REST API. This 
> change would break phosphor-webui. Since webui-vueuses Redfish this is 
> not the case for it. 
> https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/29344
> As requested, below is an updated timeline:
> With Virtual Media merged, 8 identified issues to reach parity:
> https://github.com/openbmc/webui-vue/issues?q=is%3Aissue+is%3Aopen+label%3Aphosphor-webui-feature-parity
> IBM plans to work on, with an estimated completion of mid-October:
> 
>   * Two file Firmware upload (#9)
>   * Loading webui-vue from the BMC causes content-security-policy errors
>     (#32)
>   * Radio button for DHCP - Network settings (#36)
> 
> And will work on when the Redfish interfaces for these are implemented:
> 
>   * Remote Logging (#34)
>   * SNMP (#33)
> 
> The last 2 identified issues, we are looking for community help but 
> might take these up ourselves one day:
> 
>   * Mutual TLS (#30)
>   * CSRF allow list (#29)
> 
> The last issue, Next URL forward (#28) has a review up.  Thanks Mateusz!
> 
> Please let us know if we have missed any features needed to reach parity 
> with phosphor-webui.
> 
> Would any of these outstanding issues keep the community from accepting 
> webui-vueas the standard?
> 
> Not sure officially making webui-vuethe standard means a lot, we plan to 
> update docs/ links to point at webui-vueandview as the first step 
> towards eventually deprecating / archiving phosphor-webui.
> 
> Is there any objection to this?
> 
> Some previous discussion on these topics here:
> https://lists.ozlabs.org/pipermail/openbmc/2020-August/022637.html
> https://lists.ozlabs.org/pipermail/openbmc/2020-February/020491.html
> 
> Thanks,
> Derick, Gunnar, and Yoshie

Re: Proposal to make webui-vue the standard

[Ed Tanous]

On Fri, Sep 18, 2020 at 9:36 AM Gunnar Mills <gmills@linux.vnet.ibm.com> wrote:
>
> Hi All,
>
> From some continued discussion yesterday in the GUI Design Workgroup, we would like to see the community move away from phosphor-webui and for webui-vue to become the standard. All companies on the call were in favor of this but I’ll let them chime in for themselves.
>
> As stated in previous emails there are many benefits to the webui-vue GUI.
> webui-vue adds:
>
> Improved user experience based on feedback from OpenBMC users
> Conformance with the W3C Web Content Accessibility Guidelines 2.1 specification
> Ability to easily theme to meet brand guidelines
> Dynamically generate navigation
> Language translation-ready
> Full Redfish
> Modern front-end framework with an active community and future development roadmap
>
> The phosphor-webui front-end framework, AngularJS, will sunset in June of 2021. Based on this, the most active contributing companies have moved to webui-vue

According to the OpenBMC github I only see IBM has moved.  Maybe
you're talking about forks?

> resulting in a decrease of development activity on phosphor-webui over the past six months.

Ironically, you sent this out on the same day Vue 3.0 was announced;
It looks like the next 2.X Vue release goes to 18 month support.
Hopefully Vue 2.0->3.0 porting isn't the same thing as Angular 1.X ->
2.X.

>
> We also believe webui-vue allows us to move forward other areas, for example, turning off exposing the D-Bus interfaces as a REST API. This change would break phosphor-webui. Since webui-vue uses Redfish this is not the case for it. https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/29344
>
> As requested, below is an updated timeline:
>
> With Virtual Media merged, 8 identified issues to reach parity:
> https://github.com/openbmc/webui-vue/issues?q=is%3Aissue+is%3Aopen+label%3Aphosphor-webui-feature-parity
> IBM plans to work on, with an estimated completion of mid-October:
>
> Two file Firmware upload (#9)
> Loading webui-vue from the BMC causes content-security-policy errors (#32)

This is important, and having the UI load without errors or warnings
speaks to the quality of the UI as a whole, and also allows finding
regressions much easier.  Looking forward to when this lands.

> Radio button for DHCP - Network settings (#36)
>
> And will work on when the Redfish interfaces for these are implemented:
>
> Remote Logging (#34)
> SNMP (#33)
>
> The last 2 identified issues, we are looking for community help but might take these up ourselves one day:
>
> Mutual TLS (#30)

This is used, and I think important overall for the security posture
of OpenBMC.  I would like to avoid regressing the default security of
OpenBMC in this regard.

> CSRF allow list (#29)

Do you think the person that checked in the code around the security
bug could take a look at it?  It looks like Derick wrote the commit
that needs fixed.
https://github.com/openbmc/webui-vue/commit/e080a1a7593e83a49d623ffdd452fd0e1c617889#diff-d33bbe646af7d8d45caaeb27b20b4813

>
> The last issue, Next URL forward (#28) has a review up.  Thanks Mateusz!

The current iterations of this patchset regresses security and
functionality in regards to phosphor-webui.  Once it's up to par, it
seems like a great addition.

>
> Please let us know if we have missed any features needed to reach parity with phosphor-webui.
>
> Would any of these outstanding issues keep the community from accepting webui-vue as the standard?

Known security issues (both bugs and missing features) currently
prevent me from supporting a full changeover, but it sounds like
you're hot on the heels of getting these fixed.  Once all the above
are fixed, I'm in full support of a change of defaults.

>
> Not sure officially making webui-vue the standard means a lot, we plan to update docs/ links to point at webui-vue and view as the first step towards eventually deprecating / archiving phosphor-webui.
>
> Is there any objection to this?
>
> Some previous discussion on these topics here:
> https://lists.ozlabs.org/pipermail/openbmc/2020-August/022637.html
> https://lists.ozlabs.org/pipermail/openbmc/2020-February/020491.html
>
> Thanks,
> Derick, Gunnar, and Yoshie

RE: Proposal to make webui-vue the standard

[Derick Montague]

>> resulting in a decrease of development activity on phosphor-webui over the past six months.
 
 > Ironically, you sent this out on the same day Vue 3.0 was announced;
 > It looks like the next 2.X Vue release goes to 18 month support.
 > Hopefully Vue 2.0->3.0 porting isn't the same thing as Angular 1.X ->
 > 2.X.

It will not require a complete rewrite. Google abandoned AngularJS and Angluar was a complete rewrite,
which is one reason they renamed the framework from Angular to AngularJS. We can start planning for it
now, but many of the supporting libraries are still in beta with a plan of being released by the end of
2020.

>> Loading webui-vue from the BMC causes content-security-policy errors (#32)
 
 > This is important, and having the UI load without errors or warnings
 > speaks to the quality of the UI as a whole, and also allows finding
 > regressions much easier.  Looking forward to when this lands.

Agreed. I am researching this now.

>> The last 2 identified issues, we are looking for community help but might take these up ourselves one day:
>>
>> Mutual TLS (#30)
 
 > This is used, and I think important overall for the security posture
 > of OpenBMC.  I would like to avoid regressing the default security of
 > OpenBMC in this regard.

Agreed, we will be adding the IsAuthenticated cookie check.

>> CSRF allow list (#29)
 
 > Do you think the person that checked in the code around the security
 > bug could take a look at it?  It looks like Derick wrote the commit
 > that needs fixed.
 > https://github.com/openbmc/webui-vue/commit/e080a1a7593e83a49d623ffdd452fd0e1c617889#diff-d33bbe646af7d8d45caaeb27b20b4813 

Yes, we are looking into this. I am still not quite clear what the CSRF "allowlist"
is can you point me in the right direction in phosphor-webui?

   
   

RE: Proposal to make webui-vue the standard

[Derick Montague]

>> resulting in a decrease of development activity on phosphor-webui over the past six months.
 
 > Ironically, you sent this out on the same day Vue 3.0 was announced;
 > It looks like the next 2.X Vue release goes to 18 month support.
 > Hopefully Vue 2.0->3.0 porting isn't the same thing as Angular 1.X ->
 > 2.X.

It will not require a complete rewrite. Google abandoned AngularJS and Angluar was a complete rewrite,
which is one reason they renamed the framework from Angular to AngularJS. We can start planning for it
now, but many of the supporting libraries are still in beta with a plan of being released by the end of
2020.

>> Loading webui-vue from the BMC causes content-security-policy errors (#32)
 
 > This is important, and having the UI load without errors or warnings
 > speaks to the quality of the UI as a whole, and also allows finding
 > regressions much easier.  Looking forward to when this lands.

Agreed. I am researching this now.

>> The last 2 identified issues, we are looking for community help but might take these up ourselves one day:
>>
>> Mutual TLS (#30)
 
 > This is used, and I think important overall for the security posture
 > of OpenBMC.  I would like to avoid regressing the default security of
 > OpenBMC in this regard.

Agreed, we will be adding the IsAuthenticated cookie check.

>> CSRF allow list (#29)
 
 > Do you think the person that checked in the code around the security
 > bug could take a look at it?  It looks like Derick wrote the commit
 > that needs fixed.
 > https://github.com/openbmc/webui-vue/commit/e080a1a7593e83a49d623ffdd452fd0e1c617889#diff-d33bbe646af7d8d45caaeb27b20b4813 

Yes, we are looking into this. I am still not quite clear what the CSRF "allowlist"
is can you point me in the right direction in phosphor-webui?

   
   

Re: Proposal to make webui-vue the standard

[Ed Tanous]

On Mon, Sep 21, 2020 at 10:29 AM Derick Montague
<Derick.Montague@ibm.com> wrote:
>
> >> resulting in a decrease of development activity on phosphor-webui over the past six months.
>
>  > Ironically, you sent this out on the same day Vue 3.0 was announced;
>  > It looks like the next 2.X Vue release goes to 18 month support.
>  > Hopefully Vue 2.0->3.0 porting isn't the same thing as Angular 1.X ->
>  > 2.X.
>
> It will not require a complete rewrite. Google abandoned AngularJS and Angluar was a complete rewrite,
> which is one reason they renamed the framework from Angular to AngularJS. We can start planning for it
> now, but many of the supporting libraries are still in beta with a plan of being released by the end of
> 2020.

That's good to hear that's the case.  I'm in no way saying we should
go to Vue 3.0 today, just chuckling at the state of the Javascript
frameworks as a whole.

>
> >> Loading webui-vue from the BMC causes content-security-policy errors (#32)
>
>  > This is important, and having the UI load without errors or warnings
>  > speaks to the quality of the UI as a whole, and also allows finding
>  > regressions much easier.  Looking forward to when this lands.
>
> Agreed. I am researching this now.

Sweet.

>
> >> The last 2 identified issues, we are looking for community help but might take these up ourselves one day:
> >>
> >> Mutual TLS (#30)
>
>  > This is used, and I think important overall for the security posture
>  > of OpenBMC.  I would like to avoid regressing the default security of
>  > OpenBMC in this regard.
>
> Agreed, we will be adding the IsAuthenticated cookie check.
>
> >> CSRF allow list (#29)
>
>  > Do you think the person that checked in the code around the security
>  > bug could take a look at it?  It looks like Derick wrote the commit
>  > that needs fixed.
>  > https://github.com/openbmc/webui-vue/commit/e080a1a7593e83a49d623ffdd452fd0e1c617889#diff-d33bbe646af7d8d45caaeb27b20b4813
>
> Yes, we are looking into this. I am still not quite clear what the CSRF "allowlist"
> is can you point me in the right direction in phosphor-webui?
>
>
>
>

phosphor-webui just used the stock angularjs XSRF handling.  I'm
really surprised there isn't a similar module for Vue.

The short version is, you can't expose the CSRF key to any server that
isn't the BMC.  That would be a leak of private information, and while
not fatal (as you're still protected by the session key) could be
chained to implement a CSRF attack.

The important lines of code that you need to implement are:
https://github.com/angular/angular.js/blob/6706353a71e3c11c56c0b19be03600dac57aafe1/src/ng/http.js#L429
and
https://github.com/angular/angular.js/blob/6706353a71e3c11c56c0b19be03600dac57aafe1/src/ng/http.js#L1410
and
https://github.com/angular/angular.js/blob/b4e409bf6cd81307f57e51f2f1281b05ceb6cbf2/src/ng/urlUtils.js#L136

It should be noted, because we don't expect the bmc to be doing any
cross site scripting, you can simply implement the check against the
current origin, and don't need to maintain a list anywhere like
Angular does.

Re: Proposal to make webui-vue the standard

[Ed Tanous]

On Mon, Sep 21, 2020 at 10:29 AM Derick Montague
<Derick.Montague@ibm.com> wrote:
>
> >> resulting in a decrease of development activity on phosphor-webui over the past six months.
>
>  > Ironically, you sent this out on the same day Vue 3.0 was announced;
>  > It looks like the next 2.X Vue release goes to 18 month support.
>  > Hopefully Vue 2.0->3.0 porting isn't the same thing as Angular 1.X ->
>  > 2.X.
>
> It will not require a complete rewrite. Google abandoned AngularJS and Angluar was a complete rewrite,
> which is one reason they renamed the framework from Angular to AngularJS. We can start planning for it
> now, but many of the supporting libraries are still in beta with a plan of being released by the end of
> 2020.

That's good to hear that's the case.  I'm in no way saying we should
go to Vue 3.0 today, just chuckling at the state of the Javascript
frameworks as a whole.

>
> >> Loading webui-vue from the BMC causes content-security-policy errors (#32)
>
>  > This is important, and having the UI load without errors or warnings
>  > speaks to the quality of the UI as a whole, and also allows finding
>  > regressions much easier.  Looking forward to when this lands.
>
> Agreed. I am researching this now.

Sweet.

>
> >> The last 2 identified issues, we are looking for community help but might take these up ourselves one day:
> >>
> >> Mutual TLS (#30)
>
>  > This is used, and I think important overall for the security posture
>  > of OpenBMC.  I would like to avoid regressing the default security of
>  > OpenBMC in this regard.
>
> Agreed, we will be adding the IsAuthenticated cookie check.
>
> >> CSRF allow list (#29)
>
>  > Do you think the person that checked in the code around the security
>  > bug could take a look at it?  It looks like Derick wrote the commit
>  > that needs fixed.
>  > https://github.com/openbmc/webui-vue/commit/e080a1a7593e83a49d623ffdd452fd0e1c617889#diff-d33bbe646af7d8d45caaeb27b20b4813
>
> Yes, we are looking into this. I am still not quite clear what the CSRF "allowlist"
> is can you point me in the right direction in phosphor-webui?
>
>
>
>

phosphor-webui just used the stock angularjs XSRF handling.  I'm
really surprised there isn't a similar module for Vue.

The short version is, you can't expose the CSRF key to any server that
isn't the BMC.  That would be a leak of private information, and while
not fatal (as you're still protected by the session key) could be
chained to implement a CSRF attack.

The important lines of code that you need to implement are:
https://github.com/angular/angular.js/blob/6706353a71e3c11c56c0b19be03600dac57aafe1/src/ng/http.js#L429
and
https://github.com/angular/angular.js/blob/6706353a71e3c11c56c0b19be03600dac57aafe1/src/ng/http.js#L1410
and
https://github.com/angular/angular.js/blob/b4e409bf6cd81307f57e51f2f1281b05ceb6cbf2/src/ng/urlUtils.js#L136

It should be noted, because we don't expect the bmc to be doing any
cross site scripting, you can simply implement the check against the
current origin, and don't need to maintain a list anywhere like
Angular does.

RE: Proposal to make webui-vue the standard

[Bruce Mitchell]

Phoenix Technologies Ltd. is moving forward with webui-vue and deprecating use of phosphor-webui.
We are very much looking forward to webui-vue be the standard!  The sooner the better.

> -----Original Message-----
> From: openbmc [mailto:openbmc-
> bounces+bruce_mitchell=phoenix.com@lists.ozlabs.org] On Behalf Of Ed
> Tanous
> Sent: Monday, September 21, 2020 10:39
> To: Derick Montague
> Cc: OpenBMC Maillist; Gunnar Mills
> Subject: Re: Proposal to make webui-vue the standard
> 
> On Mon, Sep 21, 2020 at 10:29 AM Derick Montague
> <Derick.Montague@ibm.com> wrote:
> >
> > >> resulting in a decrease of development activity on phosphor-webui
> over the past six months.
> >
> >  > Ironically, you sent this out on the same day Vue 3.0 was announced;
> >  > It looks like the next 2.X Vue release goes to 18 month support.
> >  > Hopefully Vue 2.0->3.0 porting isn't the same thing as Angular 1.X ->
> >  > 2.X.
> >
> > It will not require a complete rewrite. Google abandoned AngularJS
> and Angluar was a complete rewrite,
> > which is one reason they renamed the framework from Angular to
> AngularJS. We can start planning for it
> > now, but many of the supporting libraries are still in beta with a plan of
> being released by the end of
> > 2020.
> 
> That's good to hear that's the case.  I'm in no way saying we should
> go to Vue 3.0 today, just chuckling at the state of the Javascript
> frameworks as a whole.
> 
> >
> > >> Loading webui-vue from the BMC causes content-security-policy
> errors (#32)
> >
> >  > This is important, and having the UI load without errors or warnings
> >  > speaks to the quality of the UI as a whole, and also allows finding
> >  > regressions much easier.  Looking forward to when this lands.
> >
> > Agreed. I am researching this now.
> 
> Sweet.
> 
> >
> > >> The last 2 identified issues, we are looking for community help but
> might take these up ourselves one day:
> > >>
> > >> Mutual TLS (#30)
> >
> >  > This is used, and I think important overall for the security posture
> >  > of OpenBMC.  I would like to avoid regressing the default security of
> >  > OpenBMC in this regard.
> >
> > Agreed, we will be adding the IsAuthenticated cookie check.
> >
> > >> CSRF allow list (#29)
> >
> >  > Do you think the person that checked in the code around the security
> >  > bug could take a look at it?  It looks like Derick wrote the commit
> >  > that needs fixed.
> >  > https://github.com/openbmc/webui-
> vue/commit/e080a1a7593e83a49d623ffdd452fd0e1c617889#diff-
> d33bbe646af7d8d45caaeb27b20b4813
> >
> > Yes, we are looking into this. I am still not quite clear what the CSRF
> "allowlist"
> > is can you point me in the right direction in phosphor-webui?
> >
> >
> >
> >
> 
> phosphor-webui just used the stock angularjs XSRF handling.  I'm
> really surprised there isn't a similar module for Vue.
> 
> The short version is, you can't expose the CSRF key to any server that
> isn't the BMC.  That would be a leak of private information, and while
> not fatal (as you're still protected by the session key) could be
> chained to implement a CSRF attack.
> 
> The important lines of code that you need to implement are:
> https://github.com/angular/angular.js/blob/6706353a71e3c11c56c0b19b
> e03600dac57aafe1/src/ng/http.js#L429
> and
> https://github.com/angular/angular.js/blob/6706353a71e3c11c56c0b19b
> e03600dac57aafe1/src/ng/http.js#L1410
> and
> https://github.com/angular/angular.js/blob/b4e409bf6cd81307f57e51f2f
> 1281b05ceb6cbf2/src/ng/urlUtils.js#L136
> 
> It should be noted, because we don't expect the bmc to be doing any
> cross site scripting, you can simply implement the check against the
> current origin, and don't need to maintain a list anywhere like
> Angular does.