[Bug]: Internal links lose openfile parameter value

⚠️ This issue respects the following points: ⚠️

This is a bug, not a question or a configuration/webserver/proxy issue.
This issue is not already reported on Github OR Nextcloud Community Forum (I've searched it).
Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
I agree to follow Nextcloud's Code of Conduct.

Bug description

Ahoi,
when using the short file url for opening a file in a browser, the openfile query parameter gets lost on the internal redirects.

So, I do start with the request https://my.nextcloud.internal/f/1337?openfile=false. The nextcloud server redirects to something like https://my.nextcloud.internal/apps/files/files/1337?dir=/Photos&openfile=true. The file is opened.

My intention however is to open the file in the location, hence the given openfile=false, which gets lost in the redirect.

If I change the final url to https://my.nextcloud.internal/apps/files/files/1337?dir=/Photos&openfile=false, the desired state is displayed.

The issue was already reported inside another, related bug: #45731 (comment)

While the bug is fixed, this issue remains.

Steps to reproduce

Fetch any file id of a file that has a browser preview, e.g. an image/png.
Browse to https://[NEXTCLOUD_HOST]/f/[FILE_ID]?openfile=false.

Expected behavior

The browser view shows the parent directory and the chosen file is selected (details sidebar is open and file row is highlighted).

Nextcloud Server version

30

Operating system

Debian/Ubuntu

PHP engine version

None

Web server

Apache (supported)

Database engine version

PostgreSQL

Is this bug present after an update or on a fresh install?

None

Are you using the Nextcloud Server Encryption module?

None

What user-backends are you using?

Default user-backend (database)
LDAP/ Active Directory
SSO - SAML
Other

Configuration report

{
    "system": {
        "htaccess.RewriteBase": "\/html\/",
        "memcache.local": "\\OC\\Memcache\\APCu",
        "apps_paths": [
            {
                "path": "\/var\/www\/html\/apps",
                "url": "\/apps",
                "writable": false
            },
            {
                "path": "\/var\/www\/html\/custom_apps",
                "url": "\/custom_apps",
                "writable": true
            }
        ],
        "overwriteprotocol": "https",
        "overwrite.cli.url": "https:\/\/nextcloud-sub.local\/html",
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "nextcloud-sub.local"
        ],
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "pgsql",
        "version": "30.0.4.1",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbport": "",
        "dbtableprefix": "oc_",
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "allow_local_remote_servers": "1",
        "theme": "",
        "loglevel": 2,
        "maintenance": false
    }
}

List of activated Apps

Enabled:
  - activity: 3.0.0
  - app_api: 4.0.3
  - bruteforcesettings: 3.0.0
  - circles: 30.0.0
  - cloud_federation_api: 1.13.0
  - comments: 1.20.1
  - contactsinteraction: 1.11.0
  - dashboard: 7.10.0
  - dav: 1.31.1
  - federatedfilesharing: 1.20.0
  - federation: 1.20.0
  - files: 2.2.0
  - files_downloadlimit: 3.0.0
  - files_pdfviewer: 3.0.0
  - files_reminders: 1.3.0
  - files_sharing: 1.22.0
  - files_trashbin: 1.20.1
  - files_versions: 1.23.0
  - firstrunwizard: 3.0.0
  - groupfolders: 18.0.8
  - integration_openproject: 2.7.1
  - logreader: 3.0.0
  - lookup_server_connector: 1.18.0
  - nextcloud_announcements: 2.0.0
  - notifications: 3.0.0
  - oauth2: 1.18.1
  - password_policy: 2.0.0
  - photos: 3.0.2
  - privacy: 2.0.0
  - provisioning_api: 1.20.0
  - recommendations: 3.0.0
  - related_resources: 1.5.0
  - serverinfo: 2.0.0
  - settings: 1.13.0
  - sharebymail: 1.20.0
  - support: 2.0.0
  - survey_client: 2.0.0
  - systemtags: 1.20.0
  - text: 4.1.0
  - theming: 2.5.0
  - twofactor_backupcodes: 1.19.0
  - updatenotification: 1.20.0
  - user_status: 1.10.0
  - viewer: 3.0.0
  - weather_status: 1.10.0
  - webhook_listeners: 1.1.0-dev
  - workflowengine: 2.12.0
Disabled:
  - admin_audit: 1.20.0
  - encryption: 2.18.0
  - files_external: 1.22.0
  - suspicious_login: 8.0.0
  - twofactor_nextcloud_notification: 4.0.0
  - twofactor_totp: 12.0.0-dev
  - user_ldap: 1.21.0

Nextcloud Signing status

No errors have been found.

Nextcloud Logs

Additional info

No response

The openfile is not a boolean parameter with a value, it is more like HTML boolean attribute meaning if it exists (regardless of the value) it is considered true.

?openfile is the same as ?openfile=true and also as ?openfile=fooo.

You should be able to just drop the openfile at all to get the desired behavior.

@susnux

Ahoi @susnux

Thanks for the reply. I tested a bit around with your information, this is what I get:

Running https://nextcloud.internal/apps/files/files/48?dir=/Documents&openfile=true opens the file.
Running https://nextcloud.internal/apps/files/files/48?dir=/Documents&openfile=false opens the location with the file selected and the details sidebar open.
Running https://nextcloud.internal/apps/files/files/48?dir=/Documents behaves like you described it and opens the location with the file selected and the details sidebar open.

But, the short url with only the file id does not work the same way:

Running https://nextcloud.internal/f/48?openfile=true opens the file.
- leads to the URL of the first bullet above
Running https://nextcloud.internal/f/48?openfile=false opens the file.
- also leads to the URL of the first bullet above
Running https://nextcloud.internal/f/48 opens the file.
- also (!) leads to the URL of the first bullet above

So, the problem still persist.

The short url was never planned to be used with parametters.
I presume you're manually editing those urls yourself, correct?

You never found any locations on Nextcloud which would give you a short internal link with the openfile param set ?

Running https://nextcloud.internal/f/48 opens the file.

Yes the /f/FILEID endpoint always opens the file (it is a redirect to the internal route with openfile set).
So /f/123 will result in a redirect to ´/apps/files/files/123?dir=some/path&openfile=true`.

This is done on purpose for file sharing so the recipient directly sees the shared file in the viewer / office / ...

However, the use case of opening a file in its location without knowing its path is a very valid one.

Yes that's why we provide the internal file like endpoint (/f/FILEID) but this is intended to directly show / edit that file.

I see two solutions here:

We add a new option to that enpoint (query parameter)¹
You add a custom endpoint in https://github.com/nextcloud/integration_openproject that generates the internal URL just like we do with /f/FILEID.

For 1:
Either allow to pass openfile=false (true should be default for compatibility) or allow to set opendetails as we do on internal URLs and unset openfile is opendetails is set.

How do you trigger the action on your side. Do you have an URL example/pattern to give ?

I can give a quick insight for that question.

We have right now the functionality behind our own API, so the frontend requests something like

/api/v3/storages/:storage_id/file_link/:file_link_id/open?location=true

The backend translates it with this pattern:

UrlBuilder.url(storage.uri, "index.php/f/#{file_id}") + "?openfile=#{location_flag}"

and then the backend answers with a redirect having the result in the location header. This code is more then 2 years old and it definitely did the job before.

Best 👋🏽

UrlBuilder.url(storage.uri, "index.php/f/#{file_id}") + "?openfile=#{location_flag}

What is location_flag here?
Previously it used to allow a fileid only.
Nowadays it's just a Boolean as we already had the fileid in the url

No, we had here a boolean from the beginning. So, we usually pass true or false into it, as it is the flag - or query param - from the request to our own API.

The fileid is part of the path, not the query. It is inserted after index.php/f/.

@Kharonus

@Kharonus are you talking about the same thing as @wielinde ? Are you two working on the same project?

Hahaha, yes, we do work on the same project. It probably was not helpful for you if we explain our API routes pattern to explain how we used and now expect your API to act.

Let me answer you questions:

No, the extension of your API that improves integratability is not a matter of our integration app alone. Other Apps will need the same API capabilities. So your core apps should support that (again).
Your option 1 with adding a query parameter "openfile" would work for us as it did so in the past. It would be compatible with all the OpenProject installations out there expecting exactly that API.

Thank you!

Thanks!
There's one thing to clarify still, you mentioned triggering actions. Have I misundestood ?
If so, what is the param you're using to do so ?

Fix to forward the two parameters in #50807

We'll keep chatting about my last question

@Kharonus

Thanks!
There's one thing to clarify still, you mentioned triggering actions. Have I misundestood ?
If so, what is the param you're using to do so ?

I am not sure, what you mean with triggers, so maybe that was just some simple misunderstanding? With having the query parameter back we have all we need in regards to this issue.

@Kharonus Please give a thumbs up if you agree.

@Kharonus

@Kharonus maybe you could checkout the branch for the fix and see if it works for us now?

I am not sure, what you mean with triggers, so maybe that was just some simple misunderstanding? With having the query parameter back we have all we need in regards to this issue.

To quote your message prior:

And every link has a couple of convenience actions, such as open to view/edit, open the file's location (the folder) and download the file. These features were part of the very first bigger integration of our two applications a long time ago.

I do seem to remember some years ago some discussion about having a way to trigger one action directly from the url, like:

https://cloud.domain.com/f/156468?action=share would trigger the share action (which would open the sharing sidebar basically)
https://cloud.domain.com/f/156468?action=download would trigger the download action (if available)... etc

So I was checking if that wasn't something that got lost along the way.
I don't recall having seen anyone use this, so maybe I dreamed about it and it was mearly an old discussion

@skjnldsv

@skjnldsv I understand. I don't remember that we were involved in that discussion.

I can't check it on a feature branch, as I do not have a development setup running of the nextcloud/server repo. But, if this works, everything is fine:

Open URL https://my.nextcloud.rocks/index.php/f/1337?openfile=false
File is opened in location, meaning the content of the parent folder is visible, the file is "selected" as the details tab is opened for it
resulting URL should be something like this https://my.nextcloud.rocks/apps/files/files/1337?dir=/Documents&openfile=false

Navigation Menu

Repository navigation

[Bug]: Internal links lose `openfile` parameter value #50155

⚠️ This issue respects the following points: ⚠️

Bug description

Steps to reproduce

Expected behavior

Nextcloud Server version

Operating system

PHP engine version

Web server

Database engine version

Is this bug present after an update or on a fresh install?

Are you using the Nextcloud Server Encryption module?

What user-backends are you using?

Configuration report

List of activated Apps

Nextcloud Signing status

Nextcloud Logs

Additional info

6 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Bug]: Internal links lose openfile parameter value #50155

Description

⚠️ This issue respects the following points: ⚠️

Bug description

Steps to reproduce

Expected behavior

Nextcloud Server version

Operating system

PHP engine version

Web server

Database engine version

Is this bug present after an update or on a fresh install?

Are you using the Nextcloud Server Encryption module?

What user-backends are you using?

Configuration report

List of activated Apps

Nextcloud Signing status

Nextcloud Logs

Additional info

Activity

susnux commented on Jan 14, 2025

Kharonus commented on Jan 24, 2025

skjnldsv commented on Jan 30, 2025

susnux commented on Feb 5, 2025

6 remaining items

susnux commented on Feb 7, 2025

Kharonus commented on Feb 7, 2025

skjnldsv commented on Feb 7, 2025

Kharonus commented on Feb 10, 2025

skjnldsv commented on Feb 13, 2025

wielinde commented on Feb 13, 2025

skjnldsv commented on Feb 14, 2025

skjnldsv commented on Feb 14, 2025

wielinde commented on Feb 14, 2025

wielinde commented on Feb 14, 2025

skjnldsv commented on Feb 14, 2025

wielinde commented on Feb 14, 2025

Kharonus commented on Feb 17, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

[Bug]: Internal links lose `openfile` parameter value #50155