@inrupt/solid-client-access-grants
    Preparing search index...

    Function getAccessRequestFromRedirectUrl

    • Get the Access Request out of the incoming redirect from the Access Management app.

      Parameters

      • redirectUrl: string | URL

        The URL the user has been redirected to from the access management app.

      • options: {
            fetch?: {
                (input: URL | RequestInfo, init?: RequestInit): Promise<Response>;
                (input: string | URL | Request, init?: RequestInit): Promise<Response>;
            };
            returnLegacyJsonld: false;
        }

        Optional properties to customise the behaviour:

        • fetch: an authenticated fetch function. If not provided, the default session from @inrupt/solid-client-authn-browser will be used if available.
        • Optionalfetch?: {
              (input: URL | RequestInfo, init?: RequestInit): Promise<Response>;
              (input: string | URL | Request, init?: RequestInit): Promise<Response>;
          }
        • returnLegacyJsonld: false

      Returns Promise<{ accessRequest: DatasetWithId; requestorRedirectUrl: string }>

      An Access Request, and the URL to which the corresponding grant should be sent when redirecting the resource owner back to the requestor.

      0.5.0

      The redirect-based Access Request flow is deprecated, and will be removed in a future major release. Only direct access requesting and granting (e.g. issueAccessRequest and approveAccessRequest) will be supported.

    • Get the Access Request out of the incoming redirect from the Access Management app.

      Parameters

      • redirectUrl: string | URL

        The URL the user has been redirected to from the access management app.

      • Optionaloptions: {
            fetch?: {
                (input: URL | RequestInfo, init?: RequestInit): Promise<Response>;
                (input: string | URL | Request, init?: RequestInit): Promise<Response>;
            };
            returnLegacyJsonld?: true;
        }

        Optional properties to customise the behaviour:

        • fetch: an authenticated fetch function. If not provided, the default session from @inrupt/solid-client-authn-browser will be used if available.
        • Optionalfetch?: {
              (input: URL | RequestInfo, init?: RequestInit): Promise<Response>;
              (input: string | URL | Request, init?: RequestInit): Promise<Response>;
          }
        • OptionalreturnLegacyJsonld?: true

      Returns Promise<{ accessRequest: AccessRequest; requestorRedirectUrl: string }>

      An Access Request, and the URL to which the corresponding grant should be sent when redirecting the resource owner back to the requestor.

      0.5.0

      Use the RDFJS API instead. In addition, the redirect-based Access Request flow is deprecated, and will be removed in a future major release. Only direct access requesting and granting (e.g. issueAccessRequest and approveAccessRequest) will be supported.

    • Get the Access Request out of the incoming redirect from the Access Management app.

      Parameters

      • redirectUrl: string | URL

        The URL the user has been redirected to from the access management app.

      • Optionaloptions: {
            fetch?: {
                (input: URL | RequestInfo, init?: RequestInit): Promise<Response>;
                (input: string | URL | Request, init?: RequestInit): Promise<Response>;
            };
            returnLegacyJsonld?: boolean;
        }

        Optional properties to customise the behaviour:

        • fetch: an authenticated fetch function. If not provided, the default session from @inrupt/solid-client-authn-browser will be used if available.
        • Optionalfetch?: {
              (input: URL | RequestInfo, init?: RequestInit): Promise<Response>;
              (input: string | URL | Request, init?: RequestInit): Promise<Response>;
          }
        • OptionalreturnLegacyJsonld?: boolean

      Returns Promise<{ accessRequest: DatasetWithId; requestorRedirectUrl: string }>

      An Access Request, and the URL to which the corresponding grant should be sent when redirecting the resource owner back to the requestor.

      0.5.0

      The redirect-based Access Request flow is deprecated, and will be removed in a future major release. Only direct access requesting and granting (e.g. issueAccessRequest and approveAccessRequest) will be supported.

    Settings
    Member Visibility