You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Queue-it Security Framework is used to ensure that end users cannot bypass the queue by adding a server-side integration to your server.
5
+
The Queue-it Security Framework is used to ensure that end users cannot bypass the queue by adding a server-side integration to your server. It supports php >= 5.3.3.
3
6
4
7
## Introduction
5
8
When a user is redirected back from the queue to your website, the queue engine can attache a query string parameter (`queueittoken`) containing some information about the user.
@@ -12,7 +15,7 @@ The most important fields of the `queueittoken` are:
2. The validation method sees that the has no Queue-it session cookie and no `queueittoken` and sends him to the correct queue based on the configuration
@@ -36,8 +39,7 @@ The Action specifies which queue the users should be send to.
36
39
In this way you can specify which queue(s) should protect which page(s) on the fly without changing the server-side integration.
37
40
38
41
This configuration can then be downloaded to your application server.
39
-
Read more about how *[here](https://github.com/queueit/KnownUser.V3.PHP/tree/master/Documentation)*.
40
-
The configuration should be downloaded and cached for 5-10 minutes.
42
+
Read more about how *[here](https://github.com/queueit/KnownUser.V3.PHP/tree/master/Documentation)*.
41
43
42
44
### 2. Validate the `queueittoken` and store a session cookie
43
45
To validate that the user has been through the queue, use the `KnownUser::validateRequestByIntegrationConfig()` method.
@@ -46,53 +48,62 @@ If the timestamp or hash is invalid, the user is send back to the queue.
46
48
47
49
48
50
## Implementation
49
-
The KnownUser validation must *only*be done on *page requests*.
50
-
So, if you add the KnownUser validation logic to a central place, then be sure that the Triggers only fire on page requests and not on e.g. image or ajax requests.
51
+
The KnownUser validation must be done on *all requests except requests for static resources like images, css files and ...*.
52
+
So, if you add the KnownUser validation logic to a central place, then be sure that the Triggers only fire on page requests (including ajax requests) and not on e.g. image.
51
53
52
54
If we have the `integrationconfig.json` copied in the folder beside other knownuser files inside web application folder then
53
55
the following method is all that is needed to validate that a user has been through the queue:
Helper method to get the current url (you can have your own):
102
+
Helper method to get the current url (you can have your own).
103
+
The result of this helper method is used to match Triggers and as the Target url (where to return the users to).
104
+
It is therefor important that the result is exactly the url of the users browsers.
105
+
106
+
So if your webserver is e.g. behind a load balancer that modifies the host name or port, reformat the helper method as needed:
96
107
```php
97
108
function getFullRequestUri()
98
109
{
@@ -109,30 +120,30 @@ Helper method to get the current url (you can have your own):
109
120
}
110
121
```
111
122
112
-
## Installation
113
-
Copy the files: KnownUser.php, Models.php, UserInQueueService.php, UserInQueueStateCookieRepository.php, QueueITHelpers.php and IntegrationConfigHelpers.php
114
-
115
123
116
124
## Alternative Implementation
125
+
126
+
### Queue configuration
127
+
117
128
If your application server (maybe due to security reasons) is not allowed to do external GET requests, then you have three options:
118
129
119
130
1. Manually download the configuration file from Queue-it Go self-service portal, save it on your application server and load it from local disk
120
131
2. Use an internal gateway server to download the configuration file and save to application server
121
132
3. Specify the configuration in code without using the Trigger/Action paradigm. In this case it is important *only to queue-up page requests* and not requests for resources or AJAX calls.
122
-
This can be done by adding custom filtering logic before caling the `KnownUser::validateRequestByLocalEventConfig()` method.
133
+
This can be done by adding custom filtering logic before caling the `KnownUser::resolveQueueRequestByLocalConfig()` method.
123
134
124
135
The following is an example of how to specify the configuration in code:
$secretKey = ""; //Your 72 char secrete key as specified in Go Queue-it self-service platform
142
+
$secretKey = ""; //Your 72 char secret key as specified in Go Queue-it self-service platform
132
143
133
-
$eventConfig = new QueueIT\KnownUserV3\SDK\EventConfig();
144
+
$eventConfig = new QueueIT\KnownUserV3\SDK\QueueEventConfig();
134
145
$eventConfig->eventId = ""; // ID of the queue to use
135
-
$eventConfig->queueDomain = "xxx.queue-it.net"; //Domian name of the queue - usually in the format [CustomerId].queue-it.net
146
+
$eventConfig->queueDomain = "xxx.queue-it.net"; //Domain name of the queue - usually in the format [CustomerId].queue-it.net
136
147
//$eventConfig->cookieDomain = ".my-shop.com"; //Optional - Domain name where the Queue-it session cookie should be saved
137
148
$eventConfig->cookieValidityMinute = 15; //Optional - Validity of the Queue-it session cookie. Default is 10 minutes
138
149
$eventConfig->extendCookieValidity = true; //Optional - Should the Queue-it session cookie validity time be extended each time the validation runs? Default is true.
If you have some static html pages (might be behind cache servers) and you have some ajax calls from those pages needed to be protected by KnownUser library you need to follow these steps:
189
+
1) You are using v.3.5.1 (or later) of the KnownUser library.
190
+
2) Make sure KnownUser code will not run on static pages (by ignoring those URLs in your integration configuration).
0 commit comments