Dynamic cookie names?


#1

I am not sure if this is the right approach but I couldn’t think of anything else. Situation: I use a popup modal for subscriptions to a mailinglist. When someone subscribes to the mailinglis a Cookie is set giving them access to special offers and discounts. These offers (also popup modals), which come from the database, should be shown to each user once that’s why I thought cookies would be a good choice. Whenever an offer was shown to a visitor (no matter if he or she dismisses the model or clicked the action button) a cookie should be set e.g. offer 0001 meaning this offer should not shown to that visitor again. When there is a new offer this one should become offer_0002 etc. Like I said. I couldn’t think of anything else then cookies. Can someone tell me if this is the right way to go and if so, how to make this happen. Or should I take a complete different approach?
Thank you in advance


#2

You are mixing up unrelated terms. What do “someone”, “user”, “visitor” mean? A cookie is per-session within a browser, and only if the client, mostly the browser, behaves like this. So you first have to define in which situation you want to track your popup-state. But at least a cookie may be sufficient, but you also can store arrays there, no need for numbered names.


#3

@chorn. Sorry for not beeing native English. Lets leave someone, user and visitor out and lets stick to person.

  1. A person visits the site and subscribes to the mailinglist (cookie mailinglist_shown is set)
  2. The same person visits the site again and an offer is available. Offer should be shown. The person click the action button(Cookie for that particular offer should be set)
  3. The same person comes back to the site after some time and a new offer is available. etc etc etc

I hope this makes things a bit clearer


#4

Sounds workable. What’s your question exactly?


#5

@ScallioXTX. Thank you for replying. I am looking for a system (If cookies is the right way to go?) Where cookies for special offers are dynamically set and checked for. Like I said in the OP the offers are coming from the database (tbl promotions). This is what I have sofar for the mailinglist popup and first offer popup:

<?php if(!isset($_COOKIE['newsletter_popup'])): include_once "newsletter_modal.php"; ?>
<script>
	$(window).scroll(function () { 
		if($(document).scrollTop() > $(document).height()/2){
			$('#newsletterModal').modal('show');
		} 
	});
	Cookies.set('newsletter_popup', 'yes', { expires: 1000 });
</script>
<?php elseif (!isset($_COOKIE['offer_popup']) && isset($_COOKIE['newsletter_shown']) && $promotion > 0): include_once "offer_modal.php"; ?>
<script>
	$(window).scroll(function () { 
		if($(document).scrollTop() > $(document).height()/2){
			$('#offerModal').modal('show');
		} 
	});
	Cookies.set('offer_popup', 'yes', { expires: 1000 });
</script>
<?php endif; ?>
<?php if ($body_id == 'registration_completed'): ?>
<script>
	Cookies.set('newsletter_shown', 'yes', { expires: 1000 });
</script>
<?php endif; ?>

In this example, in the elseif statement, I use the static cookiename offer_popup (to check for existance and to set if not exist). Where that should become someting like offer_popup_0001 for the first, offer_popup_0002 for the second and so on. Because no matter if the person click the action button or dismisses the offer, a cookie needs to be set so the same offer will not been shown to the same person over and over again

I hope this make any sense because I don’t know how else to explain it


#6

Just to be clear: I think you do not want to track persons literally, as by DNA fingerprint, so i assume you just want to have a look at any cookie any client gives to you, whoever it is (no authorization, no authentication, if you want to have further research on this topic). I would recommend to use an array like

$_COOKIE['newsletter_popup'][0]
$_COOKIE['newsletter_popup'][1]

or speaking more generally

$_COOKIE['newsletter_popup'][$offerid]

so you can easily walk over it with foreach and have all already processed newsletters available. And you can use array_diff on the array keys combined with a list of newsletter-ids to get all tasks that are open.


#7

@chorn Nice one :+1:. I haven’t thought off that one. Thanks a lot @chorn


#8

What if someone does this?

What will you do then?


#9

@spaceshiptrooper. Not sure what you mean?


#10

Cookies are client side and can be messed with. For your use case I don’t think there is much of a security concern. But integrity can’t be assumed so you should code in some kind of fallback just in case.


#11

@Mittineague Where are you thinking of when you speak about integrity. Do you mean people that didn’t sign up to the mailing list but still are able to get the special offers?


#12

Only that if you have something like “offer id’s” 0 to 7, you need to deal with the possibly that someone might try a nonexistent "offer id 9”. Ideally it would fail silently or gracefully without displaying an error message and without going any further in the code.


#13

Now I am loosing you. What could be the purpose of someone trying a nonexistent offer id?


#14

Perhaps in many cases, no particular purpose at all. Perhaps other times to probe for vulnerabilities.


#15

Ok fair enough. And what could be a fallback? I can’t think of any


#16

As per your definition, non-existent IDs are invalid and can be ignored, just use array_diff on a whitelist of your IDs from the database, and array_intersect to get a list of the IDs the user says he has already processed.


#17

@chorn. Thank you again for replying.

This is going way over my head. Can you illustrate this with a simple example?


#18
<?php

$allids = [1,2,3,4,5];
$cookieids = [3,4,8,9];

var_dump(array_intersect($allids, $cookieids)); // seen [3,4]
var_dump(array_diff($allids, $cookieids)); // unseen [1,2,5]
var_dump(array_diff($cookieids, $allids)); // invalid [8,9]

#19

@chorn. Thanks a lot. Going to try to get my head arround this


#20

It may be non-existent, or it may be a really special offer id that specific user isn’t entitled to, but gives them a much better discount. Maybe you use a “special” id of 999 during development to set all prices to zero so you can test the order, or maybe you use a special value of “-1” to display debug information that might include stuff you don’t want others to see.