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
    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)
    The resolver over the platform's credentials service.
  • Method Summary

    Modifier and Type
    Method
    Description
    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 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.
    boolean
    isProviderMissing(String providerName)
    Whether a registration names a provider that is not installed on this platform.
    boolean
    knowsProvider(String providerName)
    Whether a credentials provider of that name is registered.
    boolean
    requiresUserAction(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.
    boolean
    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.

    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:
  • 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

      public boolean knowsProvider(String providerName)
      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

      public boolean isProviderMissing(String providerName)
      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

      public boolean requiresUserAction(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.

      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

      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
    • retriesAfterRefusal

      public boolean retriesAfterRefusal(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. 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

      public void invalidate(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. 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 one
      providerName - the registration's provider
      exoLogin - the eXo login the material was produced for