Class CaldavCredentialsResolver
It exists because there are three callers, not one: the client mints an endpoint's target and then authorizes every request on it, and the relay authorizes the requests it forwards on its own transport. Each building its own context is the divergence the contract was designed to remove — a connector kind or a channel drifting in one of them fails as a wrong provider resolved, not as a compile error.
-
Field Summary
FieldsModifier and TypeFieldDescriptionstatic final StringThe kind this connector is known by platform-wide, which is how a provider shared across connectors finds its CalDAV-specific adapter. -
Constructor Summary
ConstructorsConstructorDescriptionCaldavCredentialsResolver(org.exoplatform.services.connector.credentials.ConnectorCredentialsService connectorCredentialsService) The resolver over the platform's credentials service. -
Method Summary
Modifier and TypeMethodDescriptionauthorization(Long serverId, String providerName, String exoLogin) TheAuthorizationvalue for that account, as the configured provider produced it — Basic today, whatever a future provider answers tomorrow.voidinvalidate(Long serverId, String providerName, String exoLogin) Tells the provider that material it produced for this account was refused by the CalDAV server, so a caching provider forgets it and the next production does not hand it out again.booleanisProviderMissing(String providerName) Whether a registration names a provider that is not installed on this platform.booleanknowsProvider(String providerName) Whether a credentials provider of that name is registered.booleanrequiresUserAction(String providerName) Whether the configured provider needs anything from the user before this connector can be used — a password to type today, an authorization to grant tomorrow.booleanretriesAfterRefusal(String providerName) Whether a refused credential is worth one more attempt after invalidating it: only for a provider that produces its material itself (no user action), whose invalidation can yield something new.targetAccount(Long serverId, String providerName, String exoLogin) The account a conversation addresses, as the configured provider names it — the user's own for Personal, someone else's for a provider that authenticates as a technical account.
-
Field Details
-
CONNECTOR_KIND
The kind this connector is known by platform-wide, which is how a provider shared across connectors finds its CalDAV-specific adapter.- See Also:
-
-
Constructor Details
-
CaldavCredentialsResolver
public CaldavCredentialsResolver(org.exoplatform.services.connector.credentials.ConnectorCredentialsService connectorCredentialsService) The resolver over the platform's credentials service.- Parameters:
connectorCredentialsService- the platform's credentials service
-
-
Method Details
-
knowsProvider
Whether a credentials provider of that name is registered.- Parameters:
providerName- the name a registration is saved with- Returns:
- true when a registered provider carries that name
-
isProviderMissing
Whether a registration names a provider that is not installed on this platform. A provider an add-on contributes is absent while that add-on is not installed: that is an expected state of the platform, not an incident, and it is said once per name at WARN, without a stack, rather than on every request that meets it.A blank name is the legacy registration, served by typed credentials, and is not missing; nor is the platform's own Personal provider, which the credentials framework always registers; nor is any name on a platform whose providers cannot be listed: the provider is then asked as before and reports whatever it reports.
- Parameters:
providerName- the provider a registration is configured with, may be blank- Returns:
- true only when the providers could be listed and none carries that name
-
requiresUserAction
Whether the configured provider needs anything from the user before this connector can be used — a password to type today, an authorization to grant tomorrow.The connect button is the one asking: a provider that needs nothing must connect in a click rather than open a form nobody can fill. Answered here rather than read from the provider registry, whose REST endpoint is reserved to administrators — a user is told about their own connector, not about the instance's configuration.
An unconfigured registration answers true: every server that predates the registry carries no provider name and is served by typed credentials, and a missing configuration must never turn into a silent connection.
- Parameters:
providerName- provider the registration is configured with, possibly blank on a legacy registration- Returns:
- true when the user has something to supply
- Throws:
CalDavException- when no provider of that name is registered
-
targetAccount
The account a conversation addresses, as the configured provider names it — the user's own for Personal, someone else's for a provider that authenticates as a technical account.- Parameters:
serverId- registration the account references, or null for the legacy propertyproviderName- provider the registration is configured withexoLogin- the eXo login the target is resolved for- Returns:
- the account name to place in the URL, or null when the provider has none to offer
- Throws:
CalDavException- when no provider of that name can answer
-
authorization
TheAuthorizationvalue for that account, as the configured provider produced it — Basic today, whatever a future provider answers tomorrow. Never assembled here.Callers resolve it per request rather than once per endpoint, deliberately: material can expire between two requests of one operation, and a scheme whose header depends on the method and the URI could not be served by a value frozen earlier. The cost is the provider's: Personal caches nothing and rebuilds from the stored setting on every call - four setting reads and a decode per request today - which is accepted for the one provider whose material never expires, and is what a caching provider removes.
Material the provider hands back already expired is never sent: it is invalidated and produced once more, and only once - a provider answering expired material twice is its own defect and surfaces as the failure below.
A failure here is deliberately a plain
CalDavExceptionand never aCalDavAuthenticationException: the latter means the calendar server refused a credential, which the sync engine answers by pausing that user's account. Failing to produce a credential is a different thing — a technical account misconfigured, a provider unable to reach its own authority — and it is the connector's fault, not this user's. Pausing them one by one would bury an administrator's problem under user-level noise.- Parameters:
serverId- registration the account references, or null for the legacy propertyproviderName- provider the registration is configured withexoLogin- the eXo login the credentials are produced for- Returns:
- the header value to send
- Throws:
CalDavException- when the configured provider cannot produce credentials for the account
-
retriesAfterRefusal
Whether a refused credential is worth one more attempt after invalidating it: only for a provider that produces its material itself (no user action), whose invalidation can yield something new. A provider carrying what the user typed would hand the same password back, and the second refusal would count against the user's account in the server's lockout policy. Never throws: an unknown provider is not retried.- Parameters:
providerName- the registration's provider- Returns:
- true when a retry on fresh material makes sense
-
invalidate
Tells the provider that material it produced for this account was refused by the CalDAV server, so a caching provider forgets it and the next production does not hand it out again. Called once per refused material by the places that see one - the DAV client, the relay, the one-click connect and the BlueMind REST login: before the one retry on fresh material (EXO-89649), and again when that material is refused too, never in a loop. A provider that keeps nothing (Personal) does nothing. Never throws: an invalidation that cannot be delivered leaves the entry to expire.- Parameters:
serverId- the declared registration, or null for the legacy oneproviderName- the registration's providerexoLogin- the eXo login the material was produced for
-