Package org.exoplatform.caldav.provider

Class CaldavCredentialsResolver

java.lang.Object

org.exoplatform.caldav.provider.CaldavCredentialsResolver

@Component
public class CaldavCredentialsResolver
extends Object

The CalDAV side of the shared credentials contract: the one place that knows how this connector addresses a provider, so that the two questions a caller ever asks — which account would the material address and what header do I send — are answered from a single context.

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

Fields

Modifier and Type	Field	Description
static final String	CONNECTOR_KIND	The kind this connector is known by platform-wide, which is how a provider shared across connectors finds its CalDAV-specific adapter.

Constructor Summary

Constructors

Constructor	Description
CaldavCredentialsResolver(org.exoplatform.services.connector.credentials.ConnectorCredentialsService connectorCredentialsService)

Method Summary

Modifier and Type	Method	Description
String	authorization(Long serverId, String providerName, String exoLogin)	The Authorization value for that account, as the configured provider produced it — Basic today, whatever a future provider answers tomorrow.
void	invalidate(Long serverId, String providerName, String exoLogin)	Tells the configured provider that the material it produced for this account was refused by the calendar server, so a caching provider forgets it.
String	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.

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Field Details

CONNECTOR_KIND

public static final String 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:

• Constant Field Values

Constructor Details

CaldavCredentialsResolver

public CaldavCredentialsResolver(org.exoplatform.services.connector.credentials.ConnectorCredentialsService connectorCredentialsService)

Method Details

targetAccount

public String 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.

Parameters:

serverId - registration the account references, or null for the legacy property

providerName - provider the registration is configured with

exoLogin - 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

public String authorization(Long serverId,
 String providerName,
 String exoLogin)

The Authorization value 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 CalDavException and never a CalDavAuthenticationException: 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 property

providerName - provider the registration is configured with

exoLogin - 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

invalidate

public void invalidate(Long serverId,
 String providerName,
 String exoLogin)

Tells the configured provider that the material it produced for this account was refused by the calendar server, so a caching provider forgets it. Called exactly once per refusal by the two places that see one - the client and the relay - and never in a retry loop, as the contract asks. Personal has nothing to forget and answers nothing.

Parameters:

serverId - registration the account references, or null for the legacy property

providerName - provider the registration is configured with

exoLogin - the eXo login the refused material was produced for