The avatar pixmap is fetched from the server by the Connectionvalidator,
once it has validated the user name, it queries the avatar pixmap.
If the server does not have the avatar route, an empty pixmap is stored.
This displayName() seemed to be based on Account::user() which used
to call _credentials->user(). But then we repurposed user() to be
davUser() and this usage wasn't updated to point back to the username
used for the credentials.
Some custom server use persistent cookies with the auth token. So we should
clear all the cookies when disconnecting.
Account::clearCookieJar is only called from the HTTPCredentials. This funciton
is not used for shibboleth.
There is probably no reasons to keep the HTTP cookie anyway.
Issue #5370
The re-enables the UI, uses Qt API for importing and
stores the certificate/key in the system keychain.
People who had set up client certs need to re-setup the account. This is ok
since it was an undocumented feature anyway.
The rules to select the webdav url are now:
- If the server reports that the new chunking algorithm is working,
always use remote.php/dav/files/<username>
This capability can be overriden with an environment variable
- Otherwise, use the dav path provided by the theme, which defaults to
remote.php/webdav
This means that with the newer server, the branding can no longer override
the webdav URL. If there is still an usecase for the branding to do so, we
need to find another way to override it. But it is now more complicated to
configure as might need include the username and need different endpoint
depending on the operations (chunks or not)
Issue #4007
Events from the crash reporter suggest that the QNAM and its
child replies might get deleted before returning from this method
and the only possible cause we can see is that the inner event
loop has something to do with it.
Try keeping a ref on the QNAM while in this method to make sure
that it won't get deleted by the inner event loop.
Previously rejecting any kind of certificate meant that the user
was never asked again, even if the certificate changed.
Now we keep track of which certificates were rejected and ask again
if the ones mentioned in the ssl errors change.
mitmproxy is excellent for testing this.
This will be useful if we ever want to store account-level gui state.
I built this originally because I thought a paused account would be
this kind of state.
This moves the responsibility of asking the user or not for
credentials from the Credentials classes back to the AccountState.
fetch() now only extract credentials from the keychain, reports
the result to the AccountState which then decides if askFromUser()
should be called or not. The result is once more reported to the
AccounState.
This also replaces the HttpCredentials::queryPassword virtual
which now lets HttpCredentialsGui and HttpCredentialsText do it
the way that they prefer.
The AccountState is now the only class responsible for triggering credentials
fetching from the keychain or from the user.
With the ShibbolethRefresher out of the question it's possible
to remove the invalidateAndFetch virtual and manually call invalidateToken.
This also allows us to move that code from Account to AccountState.
In the end this also allows us to move the fetch() call from the
ConnectionValidator and use the same code path as for invalid credentials.
- Remove the copy constructor. The default constructor is fine. Having
a user defined copy constructor inhibit the move constructor.
- Pass QVariantMap arguments via const references
- Do not return a pointer to Capabilities from the account. It is a
value type and should not be used by pointer.
The proxyAuthenticationRequired() signal now goes to the
ProxyAuthHandler class. That class will try to read the proxy settings
from the keychain or ask the user about them.
We won't ask the user for credentials for explicitly configured proxies.
It also does not change how the credentials for explicitly configured
proxies are stored. (see #261)
Since we periodically recreatet the QNAM owned by the Account,
the web view could end up holding a dangling pointer to it.
Let the web view use its own QNAM, but make sure that the cookie
jars are shared so that we can grab the session token given
by the server.
The AccountManager does not belong in the libsync because it is not
part of the synchronisation algorithm, but is just an helper class
for the UI to maintain the account and read/save the config
Calling save() in the CookieJar destructor was problematic. For instance
we sometimes create a new QNAM with a new CookieJar and then call
setCookieJar() on it to assign some other jar. That destroy the fresh
jar and potentially overwrite cookies.
Also explicitly saving the account's cookies when the account is saved
is more explicit and thus more reliable than counting on the Account
destructor to do it.
The QNetworkAccessManager is reset when we are disconnected, just
before attempting to fetch the server's status.php.
This may help fix the problem described in various issues where we
get 'Connection closed' or timeout errors after the OS has woken
from sleep.
* removed broken QSsl::SslV3 default
* rewrote slotHandleErrors(): no longer claim errors which are none.
* hack reverted: lib64 was not the cause for NixOS issues related to libraries.
* refactored csync/src/csync_owncloud.c and discovered+fixed why the dav_connect was never getting the certPath+certPassoword
* cleanup of code but seems this crushed the ssl client certificate support
* fixes the https://github.com/owncloud/client/issues/69#issuecomment-69358377 issue
* lots of cleanup
* From TODO list : translate all french comments into english
* changed _pemCertificate type from QString to QByteArray
* Use a shared pointer to Account everywhere to ensure
the instance stays alive long enough for a sync to terminate
* Folder is now tied to an AccountState
* SyncEngine and OwncloudPropagator tie to an Account and use that
for all jobs they run
Issue: Since the setup wizard currently always replaces the
account, it will always wipe all folder definitions, even when
the actual changes to the account were minor.
This allows all the account state information to live in gui
while the sync-relevant data stays in libsync.
I also moved quotainfo to gui since it depends on the account state.
The account state is now managed mostly by the Account itself
instead of through Application. The gui can still control whether
an account is signed out or not.
* Stop the quota job from having an effect on account status
as it can sometimes take a long time to reply. See #2485 and
owncloud/core#12744.
* Instead of indirectly using the quota job, use the connection
validator to regularly ping the server with a basic PROPFIND for
'getlastmodified' on /.
This request was usually fast for users even when the quota PROPFIND
was slow.
