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

Detect breaking apps when enabled in the web UI #17435

Closed
PVince81 opened this issue Jul 7, 2015 · 26 comments
Closed

Detect breaking apps when enabled in the web UI #17435

PVince81 opened this issue Jul 7, 2015 · 26 comments
Milestone

Comments

@PVince81
Copy link
Contributor

PVince81 commented Jul 7, 2015

See #14754 (comment)

Basically the workflow would be as follows:

  1. User enables "someapp" in the apps manager
  2. Frontend sends a request to the Server to enable the app
  3. Server enables the app
  4. Immediately after the previous request finished, Frontend sends another parallel request to a special route to check if Server still works (to see whether the app broke something with autoloader, missing classes, etc)
  5. If Server did not give a proper response:
    1. Frontend sends a request to a privileged route of Server (one available for the admin but that does not enable any app)
    2. Server disables the broken app
    3. Frontend aknowledges this by showing a proper error message in the UI
    4. End
  6. Frontend displays success

@Raydiation @icewind1991 @MorrisJobke @nickvergessen

Regarding command line enabling, a similar workflow could be used.

@PVince81
Copy link
Contributor Author

PVince81 commented Jul 7, 2015

A similar workflow should be used when clicking "Update", if possible.

@nickvergessen
Copy link
Contributor

We are already pinging the server to get the navigation entries: abuse 😦

@PVince81
Copy link
Contributor Author

PVince81 commented Jul 7, 2015

also @DeepDiver1975 @oparoz

@PVince81
Copy link
Contributor Author

PVince81 commented Jul 7, 2015

@nickvergessen really ? Then we could reuse that.

@oparoz
Copy link
Contributor

oparoz commented Jul 7, 2015

How are you going to test if the app works? A Ping to its main route to see if you get a 200?

@PVince81
Copy link
Contributor Author

PVince81 commented Jul 7, 2015

Another suggestion I made on IRC was about having a temporary app config value "temp_enabled_until". The server would write a timestamp there which would leave the app enabled for a short time window. If within this time window the client's "ping" succeeded, the call would change it to permanently enabled. If the ping did not succeed, the app will auto-disable after the timeout.
The auto-disable is achieved by checking the timestamp in this value when retrieving the list of enabled apps.

But this could cause other issues like if an app takes longer than the timeout to enable itself / init/migrate the database.

I added this here for the sake of completeness in case it might spark even better ideas 😉

@PVince81
Copy link
Contributor Author

PVince81 commented Jul 7, 2015

@oparoz that could be an idea too. But here the main goal was to make sure the app doesn't brick ownCloud... which is even worse than just having a broken app route.

@oparoz
Copy link
Contributor

oparoz commented Jul 7, 2015

@PVince81 - But if oC is bricked then you're never going to get a reply or be able to disable the app, unless you're calling occ, no?

@BernhardPosselt
Copy link
Contributor

After a small delay, Frontend sends another parallel request to a special route to check if Server still works (to see whether the app broke something with autoloader, missing classes, etc)

Should be "immediately after the previous request finished"

@PVince81
Copy link
Contributor Author

PVince81 commented Jul 7, 2015

@oparoz yes, if OC is bricked you cannot disable the app. That's why we need a new special route that doesn't enable any apps to bypass the bricking. That route would disable it.

@PVince81
Copy link
Contributor Author

PVince81 commented Jul 7, 2015

@Raydiation thanks, updated

@DeepDiver1975
Copy link
Member

Regarding: protect use from apps breaking the instance - could this be a solution: https://github.com/fieryprophet/php-sandbox

@DeepDiver1975
Copy link
Member

@oparoz
Copy link
Contributor

oparoz commented Jul 7, 2015

I'm a bit worried about the overhead when using such parsers. Looking for data as I write this...
Runkit is on Github https://github.com/zenovich/runkit/

@BernhardPosselt
Copy link
Contributor

Probably needs to be built in PHP rather than run on top of PHP otherwise like @oparoz mentioned this will be way to slow.

@DeepDiver1975
Copy link
Member

or this: http://php.net/manual/de/runkit.sandbox.php

^ builtin ❓

@oparoz
Copy link
Contributor

oparoz commented Jul 7, 2015

^ builtin ❓

Yes, but with this requirement
"Regardless of which version of PHP is in use it must be compiled with the --enable-maintainer-zts option"

@BernhardPosselt
Copy link
Contributor

Usual PHP problem "well its possilbe but it wont work for your users"

@enoch85
Copy link
Member

enoch85 commented Jul 7, 2015

Is this related? owncloud/calendar#826 (comment)

@PVince81
Copy link
Contributor Author

PVince81 commented Jul 7, 2015

Proof of concept here: #17451

@PVince81
Copy link
Contributor Author

PVince81 commented Jul 7, 2015

Just tried ./occ with a broken app. It is still possible to set "maintenance" mode to true in the config to get back access to ./occ app:disable broken_app. So CLI isn't too big an issue.

@tflidd
Copy link
Contributor

tflidd commented Aug 16, 2015

@PVince81 I have installed the latest news app on owncloud (news app requires php5.5+, I have only php5.4). I tried to disable via ./occ app:disable news, which throws an error. And I can't turn it into the maintenance mode via ./occ!
#18315 (comment)

@MorrisJobke
Copy link
Contributor

@LukasReschke can the integrity check help here too?

@PVince81
Copy link
Contributor Author

@tflidd you can enable maintenance mode by editing config/config.php and adding/setting "maintenance" to true

@ghost ghost added this to the 9.0-next milestone Sep 21, 2015
@ghost ghost modified the milestones: 9.1-next, 9.0-current Feb 23, 2016
@ghost ghost added the old-inactive label Feb 23, 2016
@LukasReschke
Copy link
Member

Probably fixed by #17451? Thus closing. Please reopen if I'm wrong.

@lock
Copy link

lock bot commented Aug 5, 2019

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot locked as resolved and limited conversation to collaborators Aug 5, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

9 participants