|
1 | | ->You can find the latest released version [here](https://github.com/queueit/KnownUser.V3.Python/releases/latest) |
2 | | -
|
3 | 1 | # KnownUser.V3.Python |
4 | | -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 was developed and verified with Python v.2.7 and Django v.1.8. Please reach out to us if you are using another web framework, so we add it to the supported providers. |
5 | | - |
6 | | -## Introduction |
7 | | -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. |
8 | | -The most important fields of the `queueittoken` are: |
9 | | - |
10 | | - - q - the users unique queue identifier |
11 | | - - ts - a timestamp of how long this redirect is valid |
12 | | - - h - a hash of the token |
13 | | - |
14 | | - |
15 | | -The high level logic is as follows: |
16 | | - |
17 | | - |
18 | | - |
19 | | - 1. User requests a page on your server |
20 | | - 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 |
21 | | - 3. User waits in the queue |
22 | | - 4. User is redirected back to your website, now with a `queueittoken` |
23 | | - 5. The validation method validates the `queueittoken` and creates a Queue-it session cookie |
24 | | - 6. The user browses to a new page and the Queue-it session cookie will let him go there without queuing again |
25 | | - |
26 | | -## How to validate a user |
27 | | -To validate that the current user is allowed to enter your website (has been through the queue) these steps are needed: |
28 | | - |
29 | | - 1. Providing the queue configuration to the KnownUser validation |
30 | | - 2. Validate the `queueittoken` and store a session cookie |
| 2 | +Before getting started please read the [documentation](https://github.com/queueit/Documentation/tree/main/serverside-connectors) to get acquainted with server-side connectors. |
31 | 3 |
|
| 4 | +Connector was developed and verified with Python v.2.7 and Django v.1.8. Please reach out to us if you are using another web framework, so we add it to the supported providers. |
32 | 5 |
|
33 | | -### 1. Providing the queue configuration |
34 | | -The recommended way is to use the Go Queue-it self-service portal to setup the configuration. |
35 | | -The configuration specifies a set of Triggers and Actions. A Trigger is an expression matching one, more or all URLs on your website. |
36 | | -When a user enter your website and the URL matches a Trigger-expression the corresponding Action will be triggered. |
37 | | -The Action specifies which queue the users should be send to. |
38 | | -In this way you can specify which queue(s) should protect which page(s) on the fly without changing the server-side integration. |
39 | | - |
40 | | -This configuration can then be downloaded to your application server. |
41 | | -Read more about how *[here](https://github.com/queueit/KnownUser.V3.Python/tree/master/Documentation)*. |
42 | | - |
43 | | -### 2. Validate the `queueittoken` and store a session cookie |
44 | | -To validate that the user has been through the queue, use the `KnownUser.validateRequestByIntegrationConfig()` method. |
45 | | -This call will validate the timestamp and hash and if valid create a "QueueITAccepted-SDFrts345E-V3_[EventId]" cookie with a TTL as specified in the configuration. |
46 | | -If the timestamp or hash is invalid, the user is send back to the queue. |
47 | | - |
| 6 | +You can find the latest released version [here](https://github.com/queueit/KnownUser.V3.Python/releases/latest) |
48 | 7 |
|
49 | 8 | ## Implementation |
50 | 9 | The KnownUser validation must be done on *all requests except requests for static and cached pages, resources like images, css files and ...*. |
@@ -116,29 +75,9 @@ def index(request): |
116 | 75 | # This was a configuration error, so we let the user continue |
117 | 76 | print stdErr.message |
118 | 77 | ``` |
119 | | -### Protecting ajax calls |
120 | | -If you need to protect AJAX calls beside page loads you need to add the below JavaScript tags to your pages: |
121 | | - |
122 | | -``` |
123 | | -<script type="text/javascript" src="//static.queue-it.net/script/queueclient.min.js"></script> |
124 | | -<script |
125 | | - data-queueit-intercept-domain="{YOUR_CURRENT_DOMAIN}" |
126 | | - data-queueit-intercept="true" |
127 | | - data-queueit-c="{YOUR_CUSTOMER_ID}" |
128 | | - type="text/javascript" |
129 | | - src="//static.queue-it.net/script/queueconfigloader.min.js"> |
130 | | -</script> |
131 | | -``` |
132 | | - |
133 | | -## Alternative Implementation |
134 | | - |
135 | | -### Queue configuration |
136 | | - |
137 | | -If your application server (maybe due to security reasons) is not allowed to do external GET requests, then you have three options: |
138 | 78 |
|
139 | | -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 |
140 | | -2. Use an internal gateway server to download the configuration file and save to application server |
141 | | -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. |
| 79 | +## Implementation using inline queue configuration |
| 80 | +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. |
142 | 81 | This can be done by adding custom filtering logic before caling the `KnownUser.resolveQueueRequestByLocalConfig()` method. |
143 | 82 |
|
144 | 83 | The following is an example (using Django v.1.8) of how to specify the configuration in code: |
|
0 commit comments