1 of 1 people found this helpful
PD Storage is not restricted to Coaching, however many examples have been about Coaching, Welcome Page or similar. PD Storage is a global Key<->Value Storage, which allows you to throw data into and retrieve data from it at any time from within the rule engine. Key<->Value pairs ("entries") do not expire when a transaction finishs, but they persist across connections and even restarts of the process.
It basically works a little like attaching a simple (non-relational) database to MWG, but everything lives within the proxy. Every entry has a "time to live" which is reset whenever its key is called. If noone asked for the piece of information for the configured amount of time, it will be deleted.
You can use PD Storage whenever you want to keep information independent from MWG. I have created some examples in the past:
- In one example I store a users client IP address in PD Storage with a 5 Minute timeout. When the user starts to browse, MWG checks if there is already a client IP for the user name known and will store the current client IP if there is no match. If there is already a client IP stored for this user, MWG compares the current client IP and the stored value. If they differ, MWG will block Internet Access.
By doing so you efficiently "lock" a user to one client IP address. If he wants to switch to a different PC this works by not browsing for 5 minutes. Then the "Known" IP address in PD Storage is deleted, and the whole process starts from the beginning.
- A different example uses PDStorage to evaluate a next-hop proxy for the user. I configured a global PD Storage value and set it to "1". Whenever a user comes in, MWG checks if the user was already seen before. If the user is new, MWG will write a PD Storage entry for this user, and sets it to the value of the global ID. Then the global ID is incremented by one (until it reaches 8, then it is reset to 1 again).
By doing so every user has a random number between 1 and 8, which is used for picking a next-hop proxy for the user. The next-hop proxy is persistently used for this user, until the user is not seen for 30 minutes. Then PD Storage drops the value and if the users comes back, a new next-hop ID is evaluated.
This allows MWG to use a user-based next-hop proxy stickiness.
- A third example writes a number into PD Storage when a user accesses a blocked URL or virus. Whenever he accesses a malicious URL, the count is increased by 1. Once he has accessed a malicious URL 10 times I put his client IP into PD Storage for 8 hours and block it. So once he tried to continuesly access malicious URLs he is locked out, and can browse the internet when he comes back the next day. Additionally an eMail is sent to the Admin.
I hope these examples help to understand what you can do with it.
Thanks for the reply.
Based on what you stated, couldn't PD Storage essentially replace Coaching at some levels?
Could you use PD Storage to store property values that you might want to call later in the transaction or just later in a time period?
Thanks in advance,
basically PD Storage could replace Coaching yes. Spoken at a lower level both (PD Storage and Coaching) information go into some kind of a database on the hard disk. The difference here is that the Coaching database has a "fixed" layout (such as username, IP address, timestamp, etc.), while PD Storage is a key<->value storage. The coaching database is only available via the Coaching properties and only used for coaching, while PD Storage is the more "flexible" thing that allows you to do whatever you want.
So yes, you can also write an entry to PDStorage that remembers that you clicked a coaching link. But you would need some more like a landing page and redirects, so you can use the normal coaching feature, since it already provides all this functionality.
You can also use PD Strorage to store and read property values within the same transaction, but within a transaction I would recommend using a user-defined property, which becomes removed from memory after the transaction ends, while PD Storage would remain (unless you manually delete the entry before the transaction ends). PD Storage makes more sense if you want to keep information across transactions, like in the "how many malicious URLs have been called today" example I added above.
I hope this helps, the advanced features can be pretty confusing without a "real life" example :-)
Seems like PD Storage could be more useful than Coaching in certain ways.
Could I use PD Storage to keep track of how many times a user downloaded or uploaded a file? Or performed XYZ action? And then based on specific criteria, toss up a warning page or block?
1 of 1 people found this helpful
generally yes. There are two problems I see:
1.) You can not grab a "upload" or "download" directly
What defines an up/download? When I go to www.cnn.com I (technically) make approx. 100 downloads of HTML files and images. When I search at google.com I make at least one upload (search request).
So I need something more explicitly, e.g. "MediaType.isArchive" or "Body.Size greater than 1024000" (1 MB).
But once you have defined for yourself when you want to increase your counter, it is no problem. If you use the "per User" PD Storage instead of the "global" one you automatically have the key<->value pairs only valid for the current user, so you only need to increase a "UploadsDone" or "DownloadsDone" key in PD Storage by 1 once an upload/download was done.
Then you add another rule that checks the counter, and once it exceeds a certain value you block the request.
2.) You can not apply increasing a counter to an action
You cannot say "if action equals block, then increase counter". Instead you have to add an event to the rule that blockes. The event is executed before the action, so instead of only block you have to configure "increase counter" and block as an action.
But generally - yes.