As per my understanding eVars are persisted for the duration of a visit so that it can be later associated with any events. Where as lifetime of props is just that image request.
Just wanted to understand what is the scope of s.channel variable? Is that value persisted across multiple requests?
You're correct that props don't persist, and eVars can persist depend on their settings in the Adobe Analytics Console (default is visit, but they can also be set to expire on hit, or after a day/week/month, or never).
The s.campaign variable is treated identically to an eVar. You can configure how long s.campaign persists. Other variables behave just like props, like s.pageName, s.channel, and s.server. So to answer your question, s.channel behaves like a prop and expires on hit.
Related
Having an issue with the <distributed-cache> tag and Redis.
We have a <partial> Razor view that displays results of a long-running query. We acquire the data from a service injected in using #inject. The data updates very rarely, hence we wrap the content in a <distributed-cache> tag helper, with a long expires-after attribute.
However, when the data is finally updated (in another part of our app), we need to delete that key from the distributed cache, in order to force the page to update on next execution. (It's not possible for us to predict when the data will change - we can only respond to an external event.)
The problem we're having is that, despite having a fixed name attribute, the cache key appears to be impossible to predict. For example <distributed-cache name='_myQuery' vary-by-user='true'> creates a key something along the lines 7/za/Bc/ZRn/MsR/hG69TYTx1LEzqBvlyH1OLJgrpk4= in Redis.
How can I either:
Predict/calculate what the cache key is going to be in redis, so that I can delete it in another part of our application?;
Force the <distributed-cache> tag to ignore the cached value this one time? I know we have the enabled property, because this isn't going to work because the page doesn't know when to invalidate the cache.
After digging into the ASP.NET Core source I've found the CacheTagKey.cs file, which contains the GenerateKey() and GenerateHaskedKey() methods. These methods create the key from a bunch of params, then SHA256 hashes the key and returns base64.
So it looks like I can use this to predict the cache key and solve the issue.
What would be the best approach for a Play! application to remember the user? I think the only possible solution is to use the client side cookies, right? But as soon as the browser shuts down, this session is destroyed and not valid for the next request? How did/do you solve(d) this?
As for now, I ser the crypted userid in the session (per session), like this:
session("userid", user.id);
And then I use the interceptor to avoid passing parameters every when I need them oft, like described here: How to avoid passing parameters everywhere in play2?
But how to remember the user, or even beter, automatically log the user in on the next request?
EDIT: 2016-03-11
Be aware that some browser may store the session cookie for a longer period. For instance you can set in Chrome to remember the open tabs on next visit. This means that the Play Session cookie will be restored next time you open the browser.
And as of Play 2.4 the session cookie maxAge (you need to set in the application.conf) is renamed to: play.http.session.maxAge
To make the session not time-out when a users closes their browser you can use the session.maxAge parameter in the application.conf.
e.g.:
# Set session maximum age in seconds (4w)
session.maxAge=2419200
Quoting from Play 2.0 Session Documentation:
There is no technical timeout for the Session. It expires when the user closes the web browser. If you need a functional timeout for a specific application, just store a timestamp into the user Session and use it however your application needs (e.g. for a maximum session duration, maxmimum inactivity duration, etc.).
For security reasons, modern browsers will invalidate cookies on exit, and this is not something you can change simply because it would allow hackers to bad things with credentials that they do not rightfully have.
I would reevalutate whether or not you truly want the user to stay logged in, since it is usually a security risk to do so. If, however, you decide that you still want the user to stay logged in, you will have to try something that is not cookie based, and at the moment, I'm not sure what that would look like.
If you don't force a newSession or the user doesn't remove the cookies, the user should still be logged in.
It may be that your browser is set up to remove cookies when closing, or you are suffering from an external sideeffect. But I can confirm that cookies persist in my dev environment (in both Chrome and Firefox) after closing the browser.
I tried this and it worked for me. It's basically a composed Action.
def RememberAction(f: Request[AnyContent] => Result): Action[AnyContent] = {
Action { request =>
if(!request.session.get("email").isDefined && request.cookies.get("remember-email").isDefined) {
f(request).asInstanceOf[PlainResult].withSession("email" -> request.cookies.get("remember-email").get.value)
} else {
f(request)
}
}
}
Then you can use this Action in your controllers like this:
def index = RememberAction { implicit request =>
Ok("Hello World!")
}
I have an ASP NET MVC 3 app with a page with some paramater being set (let say region='North').
When this get posted back to server, I set this parameter as a session variable and return three images having their src attribute set to three different controller/getImageXy urls.
Now, these controller methods execute a query (based on a session variable) and return images.
It's kinda neat, user gets a quick reply and then those images get populated (asynchronously).
Everything works fine in FF. The initial reply has a ASP.NET_SessionID set (cookie).
FF, then, GETs three images, with the same cookie, and everything is fine.
Chrome and IE, however, don't.
They're just sending __RequestVerificationToken_Lw__.
Naturally, my session variable ("region") gets lost.
Thanks,
Igor
To answer my own question and probably save someone few hours:
The problem was that I was setting the domain attribute on session id cookie.
Why did I do that?
I copied it from the book "Proffesional ASP NET MVC 3", page 163, having the intention to set the HttpOnly flag. Quote:
You can stop script access to all cookies in your site by adding a
simple flag: HttpOnly. You can set this in the web.config like so:
<httpCookies domain=”String” httpOnlyCookies=”true” requireSSL=”false”/>
I was punished for copy pasting without thinking.
So, when I changed this to domain="", the issue was fixed.
Interestingly, FF was ignoring (or misusing) this attribute, but that is another topic.
I have a question about Pylons's request.params, which returns a MultiDict object.
Does request.params preserve the ordering of the GET parameters in a reliable way?
For example, if I were to visit http://localhost:5000/hello/index?a=1&a=2 and call request.params, could I guarantee that the MultiDict object returned would be in the following order?
>>> request.params
MultiDict([('a', '1'), ('a', '2')])
I'm guessing not, because Python seems to have a separate OrderedMultiDict object used for, well, ordered MultiDicts.
If not, is there any other way I can obtain the GET parameters and preserve their ordering in Pylons?
As I remember, even if you can get Pylons to preserve the ordering, you're not supposed to rely on that kind of behavior because not all user agents (browsers, bots, etc.) preserve ordering either and that's outside your control.
If it's part of the HTTP spec, it's not reliably followed... I doubt it is.
For example, suppose the user agent is a Python application which handles query parameters using dicts.
there is this code below in sfDoctrineGuardPlugin.
$a = sfConfig::get('app_sf_guard_plugin_success_signin_url');
var_dump($a);
$signinUrl = sfConfig::get('app_sf_guard_plugin_success_signin_url', $user->getReferer($request->getReferer()));
var_dump($signinUrl);
var_dump($user->getReferer($request->getReferer()));
It prints this:
null
string
'http://rs3.localhost/frontend_dev.php/'
(length=38)
string
'http://rs3.localhost/frontend_dev.php/miembros' (length=46)
I don't know why the the second and the third lines are different..any idea?
Regards
Javi
Weird. Spooky.
I wonder if maybe the two calls to getReferer() are in different contexts? Maybe the first (as the second arg to sfConfig::get()) implicitly uses __toString() whereas when you use var_dump(), maybe it's printing the raw value of the referer object?
Hrmm... the API says getReferer() returns a string, so that's probably not it.
What are you trying to do, BTW? Is it not honoring your app_sf_guard_plugin_success_signin_url setting from app.yml?
sfDoctrineGuardPlugin sets a referer attribute in the user, so that it can redirect back to the page originally requested. When you call getReferer it removes the attribute. (This is causing bugs for me, which is what brought me here.)
yitznewton pointed me towards a solution. The sfGuardSecurityUser class uses a method setReferer that saves a referer attribute but only if one is not yet set.
If somehow you manage to get to the executeSignin method in the sfGuard actions twice only the first referer attribute will be saved, this means that the second time the referer in the request and the referer in the user attribute can be different.
The getReferer method removes that attribute, and falls back to the request referer when the attribute is not set. this explains why calling $user->getReferer($request->getReferer()) twice returns different values sometimes.
The solution i found was to overwrite the setReferer method of the sfGuardSecurityUser in the myUser class:
public function setReferer($referer) {
$this->setAttribute('referer', $referer);
}
So far i have not found any side effects, this change ensures the user attribute will allways be the most recent, however there has to be a reason to explain why the symfony folk chose to implement this as it was.
Ive tested this by switching between apps on the login screen, allowing the session to die, killing the session manually and normally using the application and so far i have not found any side effects.