Skip to content

Commit fc9598e

Browse files
authored
Update README.md
simplified readme with link to server-side documentation repo
1 parent 13691f5 commit fc9598e

1 file changed

Lines changed: 5 additions & 66 deletions

File tree

README.md

Lines changed: 5 additions & 66 deletions
Original file line numberDiff line numberDiff line change
@@ -1,50 +1,9 @@
1-
>You can find the latest released version [here](https://github.com/queueit/KnownUser.V3.Python/releases/latest)
2-
31
# 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-
![The KnownUser validation flow](https://github.com/queueit/KnownUser.V3.Python/blob/master/Documentation/KnownUserFlow.png)
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.
313

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.
325

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)
487

498
## Implementation
509
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):
11675
# This was a configuration error, so we let the user continue
11776
print stdErr.message
11877
```
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:
13878

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.
14281
This can be done by adding custom filtering logic before caling the `KnownUser.resolveQueueRequestByLocalConfig()` method.
14382

14483
The following is an example (using Django v.1.8) of how to specify the configuration in code:

0 commit comments

Comments
 (0)