I'm working on a affiliate system in grails where users can create individual links and guests who are visiting this links get an cookie with an unique session id. If some of the guests come a few days later to my webApp again i want to know that they've been here already and wich user brought this guest to my website in the past.
How would you implement this in grails? I would say with filters. But how should i implement such a filter? Using the grails default session id wouldn't be good, because it gets invalidated and i can't upgrade the grails session lifetime as much because of the servers memory (RAM). Or is the sessionId always there and gets only refreshed, so the session lifetime in grails could be 1 hour and i'm able to track everything longer than an hour too?
Or should i set a new cookie with a unique session id especially for my purpose?
You probably need at least one filter and one cookie.
When the visitor comes to your site for the first time, I'm imagining that you define the affiliate ID as a request parameter. You probably need to create a before filter to see if the visitor already has a cookie set.
If you're just trying to associate sales with an affiliate then you don't need a unique visitor ID, just the affiliate ID that referred the visitor. Inside your filter, if the affiliate ID request parameter is present but there is no cookie, you can set the cookie. Then, when you are processing a sale, you can check if the affiliate cookie exists.
If you are trying to get more advanced metrics then you probably will need two filters (or one filter that does 2 things). One to set the cookie, and one to track the visit. Once you know the things you want to track, you can also put flag's in the user's session to keep your metrics accurate (i.e. if you don't consider each request a visit you may want to put a flag in the user's session after you increment the number of visits for the visitor.)
Related
I have a website:
10,000 pages, each page represent a category, for example: "Laptops".
On each page I am showing 20 recommended products
99% of the users are anonymous
For each user I have a context (device, user-agent and category)
For each product I have the price and the seller name
I have 2 events: outbound & purchase
I would like to re-rank (re-order, sort) the results for each new anonymous user based on the user context. I would like to re-rank based on performance (outbound & purchase).
Do you have recommendation for Specific algorithm OR tool OR service to do that? I found AWS Personalize very nice but the problem is that all of my users are anonymous so I don't believe it can be effective in my use case.
Amazon Personalize can still be used effectively when most/all users are anonymous. If you track users as visitors using a cookie or local storage, then a visitor's session ID can be considered the userId in Personalize. You will lose the continuity of stitching together the same logical user's activity across multiple sessions but you can still get in-session personalization. This requires calling PutEvents with the visitor's session ID in the sessionId field and excluding the userId field. Then when calling the GetRecommendations or GetPersonalizedRanking APIs, use the visitor's session ID as the userId field. Personalize will consider the event activity for the visitor's session when providing recommendations or reranking items.
If the visitor is a known user or later becomes known (i.e. signs in or creates an account), then pass their user ID in the userId field for PutEvents and GetRecommendations/GetPersonalizedRanking. At the next training, Personalize will associate any prior anonymous events (i.e. those with a sessionId but not a userId) to the user. The key is using a consistent sessionId across the anonymous and known events for the user for the session.
I don't know how exactly handle this situation. I have a directory where I count the pageviews for each item. For authenticated users I only count as new pageview after a delay of 200 seconds between requests. For unauthenticated users I use the IP and also 200 seconds of delay.
I use a redis SETEX to verify and then the key will expire after 200 seconds. If the key doesn't exist, then insert a new page view.
Something like this
item_id:user_id (authenticated users)
item_id:ip (unauthenticated users)
Well, this works fine until a user try to increment intentionally the page views for a specific item. I have almost 3000 views for a specific item only yesterday (in last year the page has only 150 views...). So, he created some bot to visit the page with a delay to avoid my validation.
I need to register legit pageviews, but I need to avoid the type of fraud. Any idea?
As far as I know, the best way for handling bots is a way like Google Analytics.
Google Analytics works by inserting a JavaScript snippet into the
header of your website. This snippet counts a page view whenever a
visitor triggers that JavaScript, and most bots do not process
JavaScript.
You can integrate some kind of CAPTCHA in your application to limit the number of times a user can view the page within a specific amount of time.
Upon a set number of views within a given duration (say, 20 views in under 3 minutes) from the same user or IP, make them verify the CAPTCHA each subsequent time they try to view the page.
Issue a Token for every page view request. Store the token in the Cookie.
User your already available IP or USER_ID as a filtering mechanism.
After page loaded, User the token, old_token from the cookie, Operating System, Browser Name and IP / User_ID to validate the request.
Give two different timings, like 200 second expiration time and 3600 seconds of grace time, if any of the above data matches within the grace time, don't count the page view.
You can also extend this by keeping track of page views within grace time and create some methods to validate pageview request.
I usually register the Request Time together with the Request to measure the Visit Frequency and the Visiter Count per certain Time Span.
When you register all the Request that come in with with the item_id, user_id, ip and timestamp you can afterwards process the Registers by grouping them by user_id, ip and timestamp.
That way you can find out the amount of Hits per Second and identify and exclude those who clear surpass the normal Activity Pattern without loosing Data.
Often I use the Web Service Logs to generate Statistics about Visit Frequency to certain URLs on a hourly, daily or even monthly basis.
Scenario:
In an integration in Magento 2 with Full Caching.
We have two types of customers Type 1 and Type 2. Both these types of customers are saved under same Customer Group we are distinguishing the customers based on a customer type attribute.
Customer of type 1 can belong to different departments (1 to many). When he first visits the site after login, he is redirected to select his department.
This value is saved in customer session, on run time customer can change his department that value is updated in the existing customer session.
When we access a new page we get the updated session, but if we access a page that was accessed earlier, we get the old data from session.
Options tried:
We tried to load the data from customer session factory instead of customer session, but still we are facing the issue. Our understanding is that data which is saved in customer object is loaded as new, but since our data is saved under customer session it is not returning the latest data.
For some section of the page we have used sections to load the data, but in that scenario also, if a page is accessed earlier the correct data is not loaded in first refresh, in second refresh the data is loaded properly.
We also tried to update the session data from AJAX, but that was also not much useful since that data is not getting loaded on the pages.
We also tried to use context variables, but when we log the data while saving the context variable the correct data is logged but when we try to fetch the context data, no data was returned. Also even if different context variable is set for each department, the page seems to be rendered from cache.
We can’t use Cookie since this is sensitive data, this will be the last option.
In Magento 1 we had an option to generate new Cache key by extending app\code\local\Enterprise\PageCache\Model\Processor.php,
Example
if
(isset($_COOKIE[Enterprise_PageCache_Model_Cookie::IS_USER_ALLOWED_SAVE_COOKIE]))
{ $uri .= '_' .
$_COOKIE[Enterprise_PageCache_Model_Cookie::IS_USER_ALLOWED_SAVE_COOKIE];
}
Is there any similar option available in Magento 2. If yes, please share some reference links to integrate the same.
I'm building off of a previous discussion I had with Jon Skeet.
The gist of my scenario is as follows:
Client application has the ability to create new 'PlaylistItem' objects which need to be persisted in a database.
Use case requires the PlaylistItem to be created in such a way that the client does not have to wait on a response from the server before displaying the PlaylistItem.
Client generates a UUID for PlaylistItem, shows the PlaylistItem in the client and then issue a save command to the server.
At this point, I understand that it would be bad practice to use the UUID generated by the client as the object's PK in my database. The reason for this is that a malicious user could modify the generated UUID and force PK collisions on my DB.
To mitigate any damages which would be incurred from forcing a PK collision on PlaylistItem, I chose to define the PK as a composite of two IDs - the client-generated UUID and a server-generated GUID. The server-generated GUID is the PlaylistItem's Playlist's ID.
Now, I have been using this solution for a while, but I don't understand why/believe my solution is any better than simply trusting the client ID. If the user is able to force a PK collison with another user's PlaylistItem objects then I think I should assume they could also provide that user's PlaylistId. They could still force collisons.
So... yeah. What's the proper way of doing something like this? Allow the client to create a UUID, server gives a thumbs up/down when successfully saved. If a collision is found, revert the client changes and notify of collison detected?
You can trust a client generated UUID or similar global unique identifier on the server. Just do it sensibly.
Most of your tables/collections will also hold a userId or be able to associate themselves with a userId through a FK.
If you're doing an insert and a malicious user uses an existing key then the insert will fail because the record/document already exists.
If you're doing an update then you should validate that the logged in user owns that record or is authorized (e.g. admin user) to update it. If pure ownership is being enforced (i.e. no admin user scenario) then your where clause in locating the record/document would include both the Id and the userId. Now technically the userId is redundant in the where clause because the Id will uniquely find one record/document. However adding the userId makes sure the record belongs to the user that's doing the update and not the malicious user.
I'm assuming that there's an encrypted token or session of some sort that the server is decrypting to ascertain the userId and that this is not supplied by the client otherwise that's obviously not safe.
A nice solution would be the following: To quote Sam Newman's "Building Microservices":
The calling system would POST a BatchRequest, perhaps passing in a
location where a file can be placed with all the data. The Customer
service would return a HTTP 202 response code, indicating that the
request was accepted, but has not yet been processed. The calling
system could then poll the resource waiting until it retrieves a 201
Created indicating that the request has been fulfilled
So in your case, you could POST to server but immediately get a response like "I will save the PlaylistItem and I promise its Id will be this one". Client (and user) can then continue while the server (maybe not even the API, but some background processor that got a message from the API) takes its time to process, validate and do other, possibly heavy logic until it saves the entity. As previously stated, API can provide a GET endpoint for the status of that request, and the client can poll it and act accordingly in case of an error.
Example
I have a gridview having multiple customers.
When a user clicks on the customer link then the CustomerId is stored in the Session "CustomerId".
if i open multiple customer details on multiple tabs then the Session "CustomerId" is overwritten.
so it does not make sense to store customerid in the Session.
I just want to store customerids for different tabs
Is there a way by which i can store the customerid in the viewstate of the masterpage?
(Assuming there is a single master page and multiple content pages.)
I usually try to use the URL for page-specific state info. Using session or some other shared storage can easily get messy. If the amount of state data is a bit much for being passed around in the URL, one way could be to rework the way you store the info in the session. by creating a class for holding the needed data, store several such objects in the session and identifying them by some generated request id. This request id can then be passed in the url to allow the page to pick up the correct state info from the session object.
No. The master page does not "live" between requests to different pages, you will have the same effect as storing the value in the page's viewstate.
I would normally use the querystring for this kind of thing, primarily so that the pages are bookmarkable (if you use sessionstate or form values instead, it's impossible to bookmark the page). As you say in your comment to Fredrik's answer, this does mean that users can manipulate the URL to view different customers, but this isn't a problem provided you're checking that the user is allowed to access the specified customer.
If you really don't want to use the querystring, I'd go with hidden form fields to pass the ID around. You should still be checking whether the user is allowed to see the customer though, rather than just blindly assuming that all's fine.