Do anybody knows, how I can get all logged in users in TYPO3 8.7 with extbase? Shure, I can get the fe_users sessions, but isnt there an more extbase like way?
UPDATE:
I need to get the uid's of all currently logged in users. It seems
that the is_online field holds only the timestamp from the last login.
If the user is logged out, this filed has still the timestamp. maybe
is reading the fe_sessions really the better way?
You can evalute two fields every fe_users record holds: is_online and lastlogin.
The field lastlogin is refreshed on each server access.
AFAIK the field is_online is evaluated in the form now - lastlogin > n.
So in general you have another problem, as you can not clearly detect which users are active. You only have the information when a user last time contacted the server.
The interval n is necessary as an user has no continous connection to the server. He can just read some text before he clicks to another page, but he also could close the browser window every time. And even then, if the session cookie is stored, he might use the website again and can be online immediately. Was he online the whole time?
On contrast to this a user is not even marked offline (is_online = 0) if he does an explicit logout.
Related
Background of my specific environment: I am trying to set up GA to track the user journeys around an iOS native app written in React Native. The app is in-house only and all users consent to being tracked in this way.
As I understand it, the measurement protocol allows either Client ID (cid) or User ID (uid). In the docs, both are optional, but at least one is required. Makes sense so far. Client ID is an anonymous UUIDv4 that tracks a browser or device, but not necessarily a user. User ID on the other hand is some uniquely-identifying value for a user, but may cross devices/browsers.
Initially I wrote my application using cid (as I hadn't yet read the docs on uid). Every time a user logged in the user's uuid would be stored and sent as the cid parameter. I also used session control sc. This worked - I saw sessions coming in, the User Explorer showed me the individual user uuids and sessions, etc. But upon rereading the docs, this seemed like an incorrect use of cid. It seems like cid is meant to be consistent and not something that changes as you log in and out.
As people on my app can log in and out (and possibly will - staff members may well share devices), using a long-lasting cid that is specific to the device won't allow me to track the habits of individual users and changing it per login-session, as mentioned above, feels wrong.
So I switched out cid for uid. The docs say both are optional and one is only required if the other is not used, so I figured I could just use uid and use the user's uuid in that field and it's otherwise act the same.
However, when doing it this way no hits seems to be registered at all - in "real time data" as well as the User Explorer.
Am I doing something wrong or is this by design? (If by design, are the docs wrong to say cid and uid are both optional or am I reading it incorrectly?)
Either way, best-practices-wise, do I:
Just go back to using an ephemeral cid that only changes when people log in and out. Individual sessions in the app don't change the cid but I do use sc to explicitly start and end sessions by navigation inference (click 'home' = sc=end, navigate from 'home', sc=start).
Use uid as I am trying to (i.e. switching out the current cid for uid), but also include a random cid that never changes (regardless of session lifetime, logging in and out, etc.).
Something else?
I have seen this question and its answer but it does not really answer my actual question regarding how cid and uid should actually be used, and if my issue is me or the way that GA works.
Oki so client-id is randomly generated value and must be sent with all hits.
In a non-User-ID-enabled view, Client-ID is used to calculate unique users. In a User-ID-enabled view, User-ID is used to calculate unique users
In reference to your app, you can send the unique Device id value in place of random value for client-id. This will resolve all your problems and ensure that the client id is sent with all the hits, otherwise it wont get registered in GA
I was wondering, is it possible to set an User ID and track all the history of this user, even if it's not set since the first GA event ?
For example, if a visitor comes on my website, visits few pages... And then sets his email somewhere. I can send an event with a custom unique user ID, but is it possible to link this custom unique User ID with all the previous events ?
UserId must be sent with all hits from that user. The moment you start sending it Analytics can fill in previous hits within the same session, that requires that you use Session Unification ON. All future hits on the same session must have userId, session unification will fill in previous hits but not future hits without userId.
It's not possible to do a unification with past sessions either.
I highly recommend that you read through the Session Unification Help Center Article where this behavior is well documented.
I'm having a problem with my Facebook competition where users are entering multiple times. The required fields to enter are first name, last name and email. They can not enter the same email more than once, but they are just using different email addresses. I can not delete their entries however because there is no way to "prove" that it's the same person, even though it's dead obvious (exact same first and last name, all entries within 30 seconds of one another).
Our terms and conditions say that only one entry is allowed per person, per competition but apart from the email validation I can't find a way to enforce this.
When a user likes our page (which is required to enter the competition) is the ID of that user available from the signed request? Would it be within the Facebook guidelines to store this ID along with their entry details?
Thanks
no, you need to authorize the users then you get the Facebook ID.
You then can display a diffrent page as you know this user already taken part in the competition - so you dont give them the change to submit more than once for one Facebook ID.
as this will probably to late know, you can store a cookie. but be aware that users can delete this cookie.
Greetings,
In ASP.NET, is there a way to lockout the members for 30 minutes (or given period) if they enter the password for 5 times?
This asswordAnswerAttemptLockoutDuration, won't work for me. I'm after actual invalid password entry.
Thanks Heaps.
This property is only valid for an ActiveDirectoryMembershipProvider.
You could set the MaxInvalidPasswordAttempts- and the PasswordAttempWindow properties. Then f.e. after 5 invalid passwords the user will be locked by setting the IsLockedOut property to true and can be unlocked by the UnlockUser method.
You could compare the FailedPasswordAttemptWindowStart value with DateTime.Now to check if the user could be unlocked and logged in again.
I think you shouldn't implement this feature. Although it may look like a good security idea, it actually isn't. Because with this, I can easily lock any user I want, I just need to know his login name.
We've implemented a feature similar to this a while back, and works pretty well. I haven't got the code on me, but it went something like this.
On the login page, have a function that determines if the user trying to login is locked out of the system and if that user has been locked out for less than x amount of minutes display an error message, else unlock them and proceed with the login.
Hope that makes sense, I'll try and dig the code out on Monday when I'm back in the office if you need it.
If I have a small microsite and on the first page I want to ensure that the user cannot jump to a non secure page between (e.g. 2 or 3), what would be the best way to implement this? The next page can only be seen if the user sets a certain item in a drop down box.
My first thought is cookies. If the user goes to the second page and the cookie's value is null, then there is a redirect to a failure page. If the user chooses the right value, the cookie's value is set to being a success. Would this approach work if I send a link on the 2nd page to a friend on another PC?
Is there a better way?
Cheap, downa and dirty? The cookie or session value work. Neither are reliable long term.
If you are making it so a user can only see certain info after selecting a drop down, you can hide it in a panel and only show that panel when the drop down is selected. This is the most useful if you do not mind the user having to select from drop down each time. You can use this with a cookie, as well, if you want the user to be able to see the data without selecting the drop down.
Hidden in the same page (drop down in one panel, info in another), you can keep it hidden perpetually.
If this has to be a second page, you can also put the page in another directory, and then put a web.config file in there that requires log in. You can then make it like a "log in" by "logging in" every person that answers. You end up using the Membership bits, but they are not hooked up to anything.
Cookies are not a good idea for this for one specific reason. They are under the control of the user, not you.
If a user has cookies disabled (globally or just for your site), they won't be able to get to page 2 now matter how many times they've read page 1.
In addition, if they know what your cookie contains (i.e., it's not encrypted), they can easily create it themselves or forward the method to a friend to get them to create it.
Regarding your question on whether you could send the page 2 link to someone else, cookies belong to the computer. That means the "someone else" would almost certainly not have the correct cookie for properly viewing page 2: they'd get an error.
We implemented a similar scheme (many years ago so there may be better ways to do it now). It involved storing a special "one-time" key when delivering page 1 to an IP address. The links in that page 1 were modified to include this key as an argument so that, when you requested page 2, the key was sent through as well.
The keys had a 30-minute lifetime (configurable but we ended up at 30 minutes). In order for us to deliver a page 2, the request had to come from the same IP address and have the proper key.
This prevented forwarding of links to other places and ensured the links had limited lifetimes.
Whether that's a viable solution for you is a question only you can answer. I know we got a few complaints from people who bought up page 1, then went out for a coffee. When they got back, their attempt to access page 2 was unsuccessful. We fixed this by simply redirecting them to page 1 with a suitable error message that their key had timed out.
Not perfect but, since the users were educated as to why it was happening, they understood its necessity.
If I understand your question correctly then the link you send to your friend will not work as they will not have the cookie stored in their browser memory or on their machine. This would also be true if you stored the value in Session as they will be creating their own new session when they opened the link.
To get this kind of behaviour when sharing links you will need to pass the value in a querystring i.e. when you select the desired option on page 1 and sublit the form the postback takes the selected option and then redirects to page 2 with option appended to the url as a querystring value.