I would expect to log in.
I receive the error:
Error
Access Forbidden
Invalid request
**Spreed app version: Talk 3.1.0
**Custom TURN server configured: No
**Custom STUN server configured: stun.nextcloud.com:443
Operating system: Linux 3.16.0-4-amd64 #1 SMP Debian 3.16.43-2+deb8u5 (2017-09-19) x86_64
Webserver: Apache/2.4.10 (Debian) (apache2handler)
Database: sqlite3 3.15.1
PHP version: 7.1.14
Modules loaded: Core, date, libxml, openssl, pcre, sqlite3, zlib, ctype, curl, dom, fileinfo, filter, ftp, hash, iconv, json, mbstring, SPL, PDO, session, posix, Reflection, standard, SimpleXML, pdo_sqlite, Phar, tokenizer, xml, xmlreader, xmlwriter, mysqlnd, apache2handler, apcu, exif, gd, intl, ldap, mcrypt, memcached, mysqli, pcntl, pdo_mysql, pdo_pgsql, pgsql, redis, zip, Zend OPcache
Nextcloud version: 13.0.0 - 13.0.0.14
Updated from an older Nextcloud/ownCloud or fresh install:
Where did you install Nextcloud from: Docker
Signing status
Array
List of activated apps
Enabled:
- activity: 2.6.1
- admin_audit: 1.3.0
- audioplayer: 2.2.5
- bruteforcesettings: 1.0.3
- calendar: 1.6.0
- comments: 1.3.0
- contacts: 2.1.0
- dav: 1.4.6
- deck: 0.3.0
- federatedfilesharing: 1.3.1
- federation: 1.3.0
- files: 1.8.0
- files_external: 1.4.1
- files_markdown: 2.0.1
- files_pdfviewer: 1.2.0
- files_reader: 1.2.2
- files_sharing: 1.5.0
- files_texteditor: 2.5.1
- files_trashbin: 1.3.0
- files_versions: 1.6.0
- files_videoplayer: 1.2.0
- firstrunwizard: 2.2.1
- gallery: 18.0.0
- issuetemplate: 0.3.0
- logreader: 2.0.0
- lookup_server_connector: 1.1.0
- metadata: 0.6.0
- nextcloud_announcements: 1.2.0
- notes: 2.3.2
- notifications: 2.1.2
- oauth2: 1.1.0
- ojsxc: 3.3.2
- ownpad: 0.6.5
- password_policy: 1.3.0
- provisioning_api: 1.3.0
- ransomware_protection: 1.1.0
- serverinfo: 1.3.0
- sharebymail: 1.3.0
- spreed: 3.1.0
- survey_client: 1.1.0
- systemtags: 1.3.0
- tasks: 0.9.6
- theming: 1.4.1
- twofactor_backupcodes: 1.2.3
- updatenotification: 1.3.0
- weather: 1.5.1
- workflowengine: 1.3.0
Disabled:
- encryption
- user_external
- user_ldap
Configuration (config/config.php)
{
"instanceid": "***REMOVED SENSITIVE VALUE***",
"passwordsalt": "***REMOVED SENSITIVE VALUE***",
"secret": "***REMOVED SENSITIVE VALUE***",
"trusted_domains": [
"xx",
"xx",
"xx"
],
"datadirectory": "***REMOVED SENSITIVE VALUE***",
"overwrite.cli.url": "httpxx",
"dbtype": "sqlite3",
"version": "13.0.0.14",
"logtimezone": "UTC",
"installed": true,
"mail_smtpmode": "smtp",
"mail_smtphost": "***REMOVED SENSITIVE VALUE***",
"mail_smtpport": "25",
"mail_from_address": "***REMOVED SENSITIVE VALUE***",
"mail_domain": "***REMOVED SENSITIVE VALUE***",
"maintenance": false,
"theme": "",
"loglevel": 2,
"updater.secret": "***REMOVED SENSITIVE VALUE***"
}
Are you using external storage, if yes which one: local/smb/sftp/...
Are you using encryption: no
Are you using an external user-backend, if yes which one: LDAP/ActiveDirectory/Webdav/...
Browser: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:58.0) Gecko/20100101 Firefox/58.0
Operating system:
Hi @StuartJMackintosh ,
Thanks for the report :)
Since this seems to be a problem in the Nextcloud Talk Android app,
could you please open this issue in the android app repo?
cc @mario
This is most probably a server-related config issue, right @rullzer ?
This issue may sit in that slim void between the app and the server...
Would server logs help? What would I be looking for?
@mario - yes, I think it was. I have resolved this issue after making changes today:
I am unsure which fixed it but most likely 2 or 3. Having migrated config from a different server, the first entry in the trusted domains was not the same as the main hostname, and the overwrite.cli.url setting pointed to the old server.
@StuartJMackintosh I had the same problem and I only needed to add the "add_header" line to my nginx config to solve it.
The other two changes you mentioned were not necessary in my case because the values were already set correctly.
I got the same issue with the main app. It proposed me to revert to the "old login system", which worked fine.
Most helpful comment
@mario - yes, I think it was. I have resolved this issue after making changes today:
I am unsure which fixed it but most likely 2 or 3. Having migrated config from a different server, the first entry in the trusted domains was not the same as the main hostname, and the overwrite.cli.url setting pointed to the old server.