summaryrefslogtreecommitdiffstats
path: root/chrome/browser/invalidation
Commit message (Collapse)AuthorAgeFilesLines
* Refresh access tokens for TiclInvalidationServicerlarocque@chromium.org2013-08-011-1/+17
| | | | | | | | | | | | | | | | | | | | | The Google Talk server will reject connection attempts made with a stale access token. This is often not a problem because we only need to connect on startup, when the token is fresh. It becomes a problem if we temporarily lose the network connection and need to reconnect. This change updates the TiclInvalidationService so it requests an updated access token when it receives a credentials rejected error. This should allow it to recover from connection failures caused by stale access tokens. TEST=Manual. Sign in to sync, wait > 1 hour, disable network connection, then re-enable it. Verify notifier state is enabled. BUG=264455 Review URL: https://chromiumcodereview.appspot.com/21140004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@215094 0039d316-1c4b-4281-b951-d872f2087c98
* Remove ManagedUserService::ProfileIsManaged() in favor of a method on Profile().bauerb@chromium.org2013-07-311-2/+1
| | | | | | | | | TBR=jochen@chromium.org BUG=244891 Review URL: https://chromiumcodereview.appspot.com/18526004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@214760 0039d316-1c4b-4281-b951-d872f2087c98
* Implement cloud policy invalidations using the invalidation service framework.stepco@chromium.org2013-07-312-5/+62
| | | | | | | | BUG=263287 Review URL: https://chromiumcodereview.appspot.com/19733003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@214555 0039d316-1c4b-4281-b951-d872f2087c98
* invalidations: Cancel OAuth2 request on signoutrlarocque@chromium.org2013-07-191-0/+1
| | | | | | | | | | | | When signout occurs, the TiclInvalidationService should't care about the results of any pending OAuth2 access token requests. This change modifies the logout function to cancel any pending requests. BUG=258357 Review URL: https://chromiumcodereview.appspot.com/19287012 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@212691 0039d316-1c4b-4281-b951-d872f2087c98
* Add version field to syncer::Invalidation.stepco@chromium.org2013-07-183-1/+7
| | | | | | | | BUG=260021 Review URL: https://chromiumcodereview.appspot.com/19381005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@212448 0039d316-1c4b-4281-b951-d872f2087c98
* Use a direct include of the message_loop header in chrome/browser/, part 7.avi@chromium.org2013-07-181-1/+1
| | | | | | | | | | BUG=260807 TEST=none TBR=ben@chromium.org Review URL: https://chromiumcodereview.appspot.com/19602003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@212332 0039d316-1c4b-4281-b951-d872f2087c98
* Use simpler types in invalidation notificationsrlarocque@chromium.org2013-07-123-16/+6
| | | | | | | | | | | | | | | | | | Change the detail type of NOTIFICATION_SYNC_REFRESH_LOCAL notifications from ModelTypeInvaliationMap to ModelTypeSet. The map was unnecessary because these notifications never include a payload. Change the detail types of NOTIFICATION_SYNC_REFRESH_REMOTE notifications from ModelTypeSet to ObjectIdInvalidationMap. This will allow the Android invalidator to forward invalidations that are not associated with sync types. TBR=jhawkins BUG=224161 Review URL: https://chromiumcodereview.appspot.com/18405002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@211301 0039d316-1c4b-4281-b951-d872f2087c98
* Update some includes of chrome_notification_types.hjam@chromium.org2013-07-123-3/+3
| | | | | | | | TBR=brettw Review URL: https://codereview.chromium.org/19074002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@211285 0039d316-1c4b-4281-b951-d872f2087c98
* Remove incorrect DHCECK from Invalidationsrlarocque@chromium.org2013-07-111-1/+0
| | | | | | | | | | | | | | | The DCHECK was intended to make sure that we've bothered to fetch an access token by the time we call UpdateInvalidatorCredentials(). That seemed like a reasonable assertion. However, if we're calling UpdateInvalidatorCredentials with the intention of clearing the token (which can happen when we receive NOTIFICATION_TOKENS_CLEARED) the DCHECK will fail. BUG=259320 Review URL: https://chromiumcodereview.appspot.com/18565007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@211224 0039d316-1c4b-4281-b951-d872f2087c98
* Allow Chrome OS login profile to have different default pref valuesbartfab@chromium.org2013-07-055-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | This CL is a prerequisite for putting Chrome in charge of all power management settings. Since the power management defaults on the login screen differ from those during a user session, the default values of the power prefs should be set differently for the login profile. This CL has no functional changes. It just does the following: 1/ Split chrome::RegisterUserPrefs() into: * chrome::RegisterUserProfilePrefs() * chrome::RegisterLoginProfilePrefs() 2/ Rename all other RegisterUserPrefs() methods to RegisterProfilePrefs(). BUG=241794 TEST=Updated unit and browser tests TBR=jochen@chromium.org (blanket rename of RegisterUserPrefs() in chrome/) TBR=asargent@chromium.org (blanket rename of RegisterUserPrefs() in apps/) TBR=joi@chromium.org (blanket rename of RegisterUserPrefs() in components/) Review URL: https://chromiumcodereview.appspot.com/18199003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@210310 0039d316-1c4b-4281-b951-d872f2087c98
* Remove PushMessagingApiTest's dependency in TiclInvalidationService.dcheng@chromium.org2013-07-021-6/+0
| | | | | | | | | | | This doesn't actually do very much. The dependency appears to have gone away on its own. BUG=243482 Review URL: https://chromiumcodereview.appspot.com/18390002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@209551 0039d316-1c4b-4281-b951-d872f2087c98
* Use InvalidationService (retry of r208315)rlarocque@chromium.org2013-06-2913-158/+490
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The InvalidationService was introduced r199520. That commit added the InvalidationService interface and several implementations of it, but made no use of the new code. This commit builds on that work. Up until now, TICL invalidations were handled on the sync thread. The related objects were instantiated and owned by the SyncBackendHost and SyncManager. All requests to update the set of object registrations had to be passed to the sync thread. Components that wanted to receive invalidations but were not part of sync had to route their communication with the invalidations server through ProfileSyncService to get to the sync thread. Things were a bit different on Android, but the system still tried to pretend that invalidations were owned by the sync thread. The new InvalidationService implementation is a ProfileKeyedService that is mostly independent from sync. It still relies on sync to manage sign in and fetch the appropriate auth tokens. However, it's now much easier for components outside of sync to communication with the invalidations server. The new system allows us to remove a lot of invalidations-related code from the ProfileSyncService, SyncBackendHost and SyncManager. Sync is now just one of many clients of the InvalidationService. The SyncBackendHost is responsible for forwarding messages back and forth between the InvalidationService and the sync thread. TBR=dcheng,satorux1,battre,rsimha,bauerb,sky,erg BUG=124137 Review URL: https://chromiumcodereview.appspot.com/17699005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@209264 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 208315 "Make use of InvalidationService"rlarocque@chromium.org2013-06-2513-489/+159
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | > Make use of InvalidationService > > The InvalidationService was introduced r199520. That commit added the > InvalidationService interface and several implementations of it, but > made no use of the new code. This commit builds on that work. > > Up until now, TICL invalidations were handled on the sync thread. The > related objects were instantiated and owned by the SyncBackendHost and > SyncManager. All requests to update the set of object registrations had > to be passed to the sync thread. Components that wanted to receive > invalidations but were not part of sync had to route their communication > with the invalidations server through ProfileSyncService to get to the > sync thread. Things were a bit different on Android, but the system > still tried to pretend that invalidations were owned by the sync thread. > > The new InvalidationService implementation is a ProfileKeyedService that > is mostly independent from sync. It still relies on sync to manage sign > in and fetch the appropriate auth tokens. However, it's now much easier > for components outside of sync to communication with the invalidations > server. > > The new system allows us to remove a lot of invalidations-related code > from the ProfileSyncService, SyncBackendHost and SyncManager. Sync is > now just one of many clients of the InvalidationService. The > SyncBackendHost is responsible for forwarding messages back and forth > between the InvalidationService and the sync thread. > > TBR=sky,erg > BUG=124137 > > Review URL: https://chromiumcodereview.appspot.com/15580002 TBR=rlarocque@chromium.org Review URL: https://codereview.chromium.org/17610004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@208347 0039d316-1c4b-4281-b951-d872f2087c98
* Make use of InvalidationServicerlarocque@chromium.org2013-06-2513-159/+489
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The InvalidationService was introduced r199520. That commit added the InvalidationService interface and several implementations of it, but made no use of the new code. This commit builds on that work. Up until now, TICL invalidations were handled on the sync thread. The related objects were instantiated and owned by the SyncBackendHost and SyncManager. All requests to update the set of object registrations had to be passed to the sync thread. Components that wanted to receive invalidations but were not part of sync had to route their communication with the invalidations server through ProfileSyncService to get to the sync thread. Things were a bit different on Android, but the system still tried to pretend that invalidations were owned by the sync thread. The new InvalidationService implementation is a ProfileKeyedService that is mostly independent from sync. It still relies on sync to manage sign in and fetch the appropriate auth tokens. However, it's now much easier for components outside of sync to communication with the invalidations server. The new system allows us to remove a lot of invalidations-related code from the ProfileSyncService, SyncBackendHost and SyncManager. Sync is now just one of many clients of the InvalidationService. The SyncBackendHost is responsible for forwarding messages back and forth between the InvalidationService and the sync thread. TBR=sky,erg BUG=124137 Review URL: https://chromiumcodereview.appspot.com/15580002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@208315 0039d316-1c4b-4281-b951-d872f2087c98
* Use a direct include of strings headers in chrome/browser/i*/.avi@chromium.org2013-06-111-1/+1
| | | | | | | | | | BUG=247723 TEST=none TBR=ben@chromium.org Review URL: https://chromiumcodereview.appspot.com/15798020 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@205375 0039d316-1c4b-4281-b951-d872f2087c98
* Store the username of the custodian of the managed user.akuegel@chromium.org2013-06-061-1/+0
| | | | | | | | | | | | To create a managed user, someone has to be signed in. We store the username immediately after the new managed profile has been created as a profile preference. BUG=241387 Review URL: https://chromiumcodereview.appspot.com/15907009 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@204660 0039d316-1c4b-4281-b951-d872f2087c98
* chrome: Use base::MessageLoop. (Part 3)xhwang@chromium.org2013-05-281-1/+1
| | | | | | | | | | | | This CL updates chrome/browser/* other than chrome/browser/ui which is in another CL. BUG=236029 TBR=brettw Review URL: https://chromiumcodereview.appspot.com/14113053 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@202664 0039d316-1c4b-4281-b951-d872f2087c98
* Remove references to Profile from browser_context_keyed_service.phajdan.jr@chromium.org2013-05-226-19/+22
| | | | | | | | | BUG=227219 R=joi@chromium.org Review URL: https://codereview.chromium.org/15517005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@201634 0039d316-1c4b-4281-b951-d872f2087c98
* Move ProfileKeyedService infrastructure to a componentphajdan.jr@chromium.org2013-05-205-5/+5
| | | | | | | | | | | Renames of the classes and methods will follow in separate patch(es). BUG=227219 R=erg@chromium.org, joi@chromium.org Review URL: https://codereview.chromium.org/14743010 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@201167 0039d316-1c4b-4281-b951-d872f2087c98
* Fix some sign out bugs in TiclInvalidationServicerlarocque@chromium.org2013-05-202-18/+27
| | | | | | | | | | | | | | | | | | | | | | | The first issue is that TiclInvalidationService should only respond to invalidations related to its own profile. That's been fixed by passing the appropriate parameters when registering with the notification service. Second, the management of the invalidator storage within the TiclInvalidationService has been modified. Clients of this service could ask for the invalidation client ID at any time, and we must be prepared to send them a valid response. Therefore, it is not possible to allow the TiclInvalidationService to exist without a valid InvalidatorStorage member. Fortunately, the InvalidationService code is not currently in use, so these bugs were harmless. BUG=124137 Review URL: https://chromiumcodereview.appspot.com/15176003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@201120 0039d316-1c4b-4281-b951-d872f2087c98
* Commit InvalidationService implementationsrlarocque@chromium.org2013-05-1020-0/+2458
This commit introduces a new ProfileKeyedService, the InvalidationService. Clients may register with this service to receive notifications from a server informing them when they need to fetch updates to their cached state. (In other words, they will receive notifications when their cache has become invalid.) There are three different implementations of this service, all of which inherit from InvalidationFrontend. The current provider of invalidations, ProfileSyncService, also inherits from this interface. The TiclInvalidationService receives notifications through the C++ version of the googlecacheinvalidation (aka. TICL) library. It is used on Chromium for Desktop operating systems. The AndroidInvalidationService receives notifications by listening to the in-process NotificationService (content/public/browser/notification_service.h). The code that actually sends these notifications is a small bridge from Java-land, which is not affected by this CL. The P2PInvalidationService uses XMPP peer-to-peer connections to send and receive invalidations. This has not been used in Chromium for a very long time. We keep it around because some of our integration tests rely on it. This CL also includes an InvalidationServiceFactory to help manage the selection and construction of these InvalidationServices. The tests for these new services are based on a modified version of sync/notifier/invalidator_test_template.h. The P2PInvalidationService is not tested at all because it is itself a test-only utility. In addition to the new code, this CL moves around some old code to help populate a new directory, chrome/browser/invalidation. We're trying to separate invalidations from sync, so the chrome/browser/sync/invalidations directory was no longer needed. Finally, note that this commit does not change Chromium in any way. It adds new classes and test for them, but the rest of the code has not been modified to make use of them. Those changes will happen in a future CL. BUG=124137 Review URL: https://chromiumcodereview.appspot.com/13991017 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@199520 0039d316-1c4b-4281-b951-d872f2087c98