[Bug]: File Request feature "suddenly" does not ask for nickname any more
Nobody has claimed this yet.
- Dominant language
- PHP
- Stars
- 36.9k
- Forks
- 5.2k
- Avg merge
- 2d 3h
- Merged PRs (30d)
- 713
Description
⚠️ 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
Installed Nextcloud 33 fresh a couple of days ago. Used it to create Shares via links, to let people be able to upload files. I used the File Request feature (upload only) for this. (But also tried the other options.)
When I tested the Share links, there was a modal, asking (forcing) the recipient to input a nickname. The nickname then also was used as a directory for the uploaded files. After entering the nickname, the recipient's browser remembered this nickname. All this was accompanied by the small avatar in the top right corner showing the first letter of the provided nickname.
Two or three days later (yesterday, at time of writing), all this stopped. I noticed, that "suddenly" this modal does not appear any more. The user is not asked and forced to provide a nickname. The avatar shows a question mark and sais "You are currently not identified" and offers the option to "Set public name".
Only after clicking "Set public name" the modal for guest identification appears.
At first I thought that it maybe a browser cache problem. These things often times are a spoke in the wheel, when testing websites. But in the meantime I tried this on three different platforms and in multiple browsers: the behavior stays the same: no guest identification modal any more.
Steps to reproduce
I don't know how to reproduce this, sorry. All I did was:
- Nextcloud GUI file browser
- Selected a directory
- Clicked on Share options
- Created a public Share link
When visiting this link, at first there was a modal for guest identification. Now there isn't any more.
Expected behavior
I expected the modal for guest identification to appear every time a new recipient uses such a Share link.
To be honest: I also expected that, when creating such a Share link, it is an option whether guest identification should be enforced or not (and thus anonymous with no directory is ok). I also expected an option, or at least an info about, how long the user's browser will (or should) remember the identified guest. (Well, it seems I'm not the only one wondering about that.) See this a kind of a feature request.
Nextcloud Server version
33
Operating system
Debian/Ubuntu
PHP engine version
PHP 8.4
Web server
Apache (supported)
Database engine version
MariaDB
Is this bug present after an update or on a fresh install?
Fresh Nextcloud Server install
Are you using the Nextcloud Server Encryption module?
Encryption is Disabled
What user-backends are you using?
- Default user-backend (database)
- LDAP/ Active Directory
- SSO - SAML
- Other
Configuration report
{
"system": {
"instanceid": "***REMOVED SENSITIVE VALUE***",
"passwordsalt": "***REMOVED SENSITIVE VALUE***",
"secret": "***REMOVED SENSITIVE VALUE***",
"trusted_domains": [
"192.168.0.192"
],
"datadirectory": "***REMOVED SENSITIVE VALUE***",
"dbtype": "mysql",
"version": "33.0.0.16",
"overwrite.cli.url": "http:\/\/192.168.0.192",
"htaccess.RewriteBase": "\/",
"dbname": "***REMOVED SENSITIVE VALUE***",
"dbhost": "***REMOVED SENSITIVE VALUE***",
"dbtableprefix": "oc_",
"mysql.utf8mb4": true,
"dbuser": "***REMOVED SENSITIVE VALUE***",
"dbpassword": "***REMOVED SENSITIVE VALUE***",
"installed": true,
"maintenance": false,
"simpleSignUpLink.shown": false,
"memcache.local": "\\OC\\Memcache\\APCu",
"default_phone_region": "DE",
"filelocking.enabled": true,
"memcache.locking": "\\OC\\Memcache\\Redis",
"redis": {
"host": "***REMOVED SENSITIVE VALUE***",
"port": 0,
"timeout": 0
},
"config_preset": 2,
"forbidden_filename_basenames": [
"con",
"prn",
"aux",
"nul",
"com0",
"com1",
"com2",
"com3",
"com4",
"com5",
"com6",
"com7",
"com8",
"com9",
"com\u00b9",
"com\u00b2",
"com\u00b3",
"lpt0",
"lpt1",
"lpt2",
"lpt3",
"lpt4",
"lpt5",
"lpt6",
"lpt7",
"lpt8",
"lpt9",
"lpt\u00b9",
"lpt\u00b2",
"lpt\u00b3"
],
"forbidden_filename_characters": [
"<",
">",
":",
"\"",
"|",
"?",
"*",
"\\",
"\/"
],
"forbidden_filename_extensions": [
" ",
".",
".filepart",
".part"
],
"mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
"mail_smtpname": "***REMOVED SENSITIVE VALUE***",
"mail_domain": "***REMOVED SENSITIVE VALUE***",
"mail_from_address": "***REMOVED SENSITIVE VALUE***",
"mail_smtpmode": "smtp",
"mail_smtphost": "***REMOVED SENSITIVE VALUE***",
"mail_smtpauth": true,
"mail_smtpport": "465",
"mail_sendmailmode": "smtp",
"mail_smtpstreamoptions": {
"ssl": {
"allow_self_signed": false,
"verify_peer": true,
"verify_peer_name": true
}
},
"mail_smtpsecure": "ssl"
}
}
List of activated Apps
Enabled:
- activity: 6.0.0-dev.0
- app_api: 33.0.0
- bruteforcesettings: 6.0.0-dev.0
- calendar: 6.2.1
- circles: 33.0.0
- cloud_federation_api: 1.17.0
- comments: 1.23.0
- contacts: 8.4.1
- contactsinteraction: 1.14.1
- dashboard: 7.13.0
- dav: 1.36.0
- federatedfilesharing: 1.23.0
- federation: 1.23.0
- files: 2.5.0
- files_downloadlimit: 5.1.0-dev.0
- files_pdfviewer: 6.0.0-dev.0
- files_reminders: 1.6.0
- files_sharing: 1.25.2
- files_trashbin: 1.23.0
- files_versions: 1.26.0
- firstrunwizard: 6.0.0-dev.0
- guests: 4.6.0
- logreader: 6.0.0
- lookup_server_connector: 1.21.0
- mail: 5.7.3
- nextcloud_announcements: 5.0.0
- notes: 4.13.0
- notifications: 6.0.0
- oauth2: 1.21.0
- password_policy: 5.0.0-dev.0
- photos: 6.0.0-dev.0
- privacy: 5.0.0-dev.0
- profile: 1.2.0
- provisioning_api: 1.23.0
- recommendations: 6.0.0-dev.0
- related_resources: 4.0.0-dev.0
- richdocuments: 10.1.0
- richdocumentscode: 25.4.903
- serverinfo: 5.0.0-dev.0
- settings: 1.16.0
- sharebymail: 1.23.0
- spreed: 23.0.2
- support: 5.0.0
- survey_client: 5.0.0-dev.0
- systemtags: 1.23.0
- text: 7.0.0-dev.3
- theming: 2.8.0
- theming_customcss: 1.20.0
- twofactor_backupcodes: 1.22.0
- twofactor_totp: 15.0.0-dev.0
- twofactor_webauthn: 2.6.0
- updatenotification: 1.23.0
- user_status: 1.13.0
- viewer: 6.0.0-dev.0
- webhook_listeners: 1.5.0
- workflowengine: 2.15.0
Disabled:
- admin_audit: 1.23.0
- encryption: 2.21.0
- files_accesscontrol: 4.0.0 (installed 4.0.0)
- files_external: 1.25.1
- suspicious_login: 11.0.0-dev.0
- twofactor_nextcloud_notification: 7.0.0
- user_ldap: 1.24.0
- weather_status: 1.13.0 (installed 1.13.0)
Nextcloud Signing status
No errors have been found.
Nextcloud Logs
No specific log output is generated when this is happening – or not happening.
Additional info
I assume this is a bug. If this behavior is due a (mis-)configuration of Nextcloud on my side, please forgive me. Please tell me where to find the option I probably accidentally checked (or unchecked) somewhere in a place on the GUI unknown to me.
Thank you!
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start at the GUI file browser's Share options and create a public File Request link, then compare a new recipient's first visit with the Set public name flow. Done means the guest identification modal behavior is reproduced and its expected appearance for new recipients is covered by a regression test.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- php
- Domain
- backend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Needs clarification
- Newbie friendliness
- 45/100