Locked out from OC10 when web is the default app but crashes

[jvillafanez]

Coming from https://central.owncloud.org/t/web-ui-redirection-2-0-its-even-worse/39322

1. Install OC10 and web
2. Set web as default app for the user
3. Make web crash somehow (likely some wrong configuration somewhere)

Expected behaviour

The user can somehow revert the default app to the old UI

Actual behaviour

It isn't easy to revert the default app for the user. The occ command to set the default app is undocumented (as far as I know), and OC 10 doesn't provide an easy way to change the default app in case the user manage to enter (which might not happen if he doesn't know the url).
Note that, since the web app crashes, the user can't revert the default app from the web app.

Server configuration

Operating system:

Web server:

Database:

PHP version:

ownCloud version: (see ownCloud admin page)

Updated from an older ownCloud or fresh install:

Where did you install ownCloud from:

Signing status (ownCloud 9.0 and above):

Login as admin user into your ownCloud and access 
http://example.com/index.php/settings/integrity/failed 
paste the results into https://gist.github.com/ and puth the link here.

The content of config/config.php:

Log in to the web-UI with an administrator account and click on
'admin' -> 'Generate Config Report' -> 'Download ownCloud config report'
This report includes the config.php settings, the list of activated apps
and other details in a well sanitized form.

or 

If you have access to your command line run e.g.:
sudo -u www-data php occ config:list system
from within your ownCloud installation folder

*ATTENTION:* Do not post your config.php file in public as is. Please use one of the above
methods whenever possible. Both, the generated reports from the web-ui and from occ config:list
consistently remove sensitive data. You still may want to review the report before sending.
If done manually then it is critical for your own privacy to dilligently
remove *all* host names, passwords, usernames, salts and other credentials before posting.
You should assume that attackers find such information and will use them against your systems.

List of activated apps:

If you have access to your command line run e.g.:
sudo -u www-data php occ app:list
from within your ownCloud installation folder.

Are you using external storage, if yes which one: local/smb/sftp/...

Are you using encryption: yes/no

Are you using an external user-backend, if yes which one: LDAP/ActiveDirectory/Webdav/...

LDAP configuration (delete this part if not used)

With access to your command line run e.g.:
sudo -u www-data php occ ldap:show-config
from within your ownCloud installation folder

Without access to your command line download the data/owncloud.db to your local
computer or access your SQL server remotely and run the select query:
SELECT * FROM `oc_appconfig` WHERE `appid` = 'user_ldap';


Eventually replace sensitive data as the name/IP-address of your LDAP server or groups.

Client configuration

Browser:

Operating system:

Logs

Web server error log

Insert your webserver log here

ownCloud log (data/owncloud.log)

Insert your ownCloud log here

Browser log

Insert your browser log here, this could for example include:

a) The javascript console log
b) The network log 
c) ...

[jvillafanez]

There are some challenges to take into account:

• Checking that the target app is enabled isn't enough. The current code already does that. Note that the app state is stored in the DB, so the app could be reported as enabled but the actual code could have been removed.
• Code for the app could have been removed.
• Pinging the target url could be successful, but the app could still be in a broken state (page loads but js code could break the page or make it unusable).

So the main problems are that we can't rely on the app itself to revert the default app because it could be in a broken state (as shown in this ticket), and that we can't ensure a good state of the default app before telling the browser to load it.

[jvillafanez]

Proposal: create a registration mechanism so apps can be selectable as default apps.

This should give us a couple of advantages over the current mechanism:

• If the code is missing, the app won't be able to register itself. This will lead core to reject the chosen default app and select the next one
• Apps can implement their own checks, so the app itself will be responsible to decide whether it can act as a default app NOW, or not. The app could have invalid configuration, missing connection to required services, invalid credentials, etc, so the app can decide not to act as default app even for particular users or groups.
• It's assumed that the apps can provide a way for the users to deselect the app as default app, assuming the check for the app goes through.

The second point is the most important one because it provides a way for core to ensure more or less reliably that the app selected as default won't break in weird ways.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions.

[jvillafanez]

It seems the app should take care of this issue. The app could fail to load some asset and crash, making the web UI unusable. In this case, the app should provide a solution: either allow restoring the default app, or provide a way to change the default app.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions.

[github-actions]

This issue has been automatically closed.