Download the PHP package vanilla/vanilla-connect without Composer
On this page you can find all versions of the php package vanilla/vanilla-connect. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package vanilla-connect
VanillaConnect Library for PHP
VanillaConnect Library contains everything you need to use the VanillaConnect plugins with a PHP Project.
How it works
As the provider, you will receive signed authentication requests. If the user that issued the request is currently logged on you will be able to issue an authentication response containing the user information (also known as "claim") that will log in the user on your forum.
ClientID & Secret
The ClientID is used to identify the issuer of the authentication request. It will be specified inside a JSON Web Token (JWT). This tells you from "where" the authentication request is coming from.
The Secret is used to sign the JWT. This ensures that both the issuer and the provider are who they claim to be. Never expose or give your secret to anyone.
Claim
The claim is the "body" of the JWT. When authenticating a request you need to provide the user's information so that we can put them in the response JWT.
Usually the response's claim contains the following fields:
- id: Unique identifier of the user on your your platform. This is usually a number but can be any string.
- name: The name of the user.
- email: The email of the user.
- photourl: The url of the photo of the user.
- roles: A comma separated list of Vanilla's roles name.
Everything is optional but "id". "name" and "email" are necessary if you want users to be created automatically on Vanilla's side.
URLs Whitelisting
The provider needs to whitelist every URL that can receive a response.
Why?
This security measure makes sure that the authentication response is sent to a trusted party. When an authentication request is made, the JWT's claim will contain the redirect URL to which the authentication response should be sent to. That URL must have been "whitelisted" by the provider otherwise the response's claim will be replaced by an error.
How?
You just create a list of every URLs {Scheme}{UserPwd}{Host}{Path} that are whitelisted.
If you really need to you can use wildcards (*) to specify that this part of the URL can be anything. It is best if you can avoid using wildcards because they weaken the security of the whitelist.
- Scheme: Can be
https://,http://or//if you want to allow both. You cannot use wildcards here. - UserPwd: (Optional) You will probably not need this. Looks like this:
user:password@. - Host: Can be an IP address or a domain name. You can optionally specify a port too.
- Note that for domains, for security reasons, you cannot use a wildcards for the TLD or main domain.
- Path: Needs to start with
/. Usually, it should be/authenticate/vanilla-connect/{clientID}
Example: https://forum.yourdomain.com/authenticate/vanilla-connect/1234.
Notes:
- The query string and fragment parts of the URLs are not validated and must not be present in the whitelist URL.
- The validation is case insensitive.
For more example check the Usage example section.
