Indeed.Quote from Arantor on April 25th, 2012, 07:05 PM There isn't at present but I suppose it could be; since you need to be signed in, and they need to be signed in, between them it's fairly trivial to do. It will probably be more useful than seeing what guests are online, actually ;)
Heck, when we implement custom groups, friend lists will suddenly become trendier to use -- if only because you'll be able to specify your own 'custom' colors for them, mesays.
nend
-
-
- When is a theme, no longer what it was when installed?
- Posts: 165
Nao
- Dadman with a boy
-
-
- Posts: 16,082
SMF does send a request pm...
Arantor
-
-
- As powerful as possible, as complex as necessary.
- Posts: 14,278
No it doesn't, it doesn't tell anyone who has friended them in any fashion,
When we unite against a common enemy that attacks our ethos, it nurtures group solidarity. Trolls are sensational, yes, but we keep everyone honest. | Game Memorial
Nao
- Dadman with a boy
-
-
- Posts: 16,082
Oh. Then I guess it's an UltimateProfile feature.
To do: option for groups to notify users on add, and on remove. (2 different options.)
Arantor
-
-
- As powerful as possible, as complex as necessary.
- Posts: 14,278
So, putting aside the friend stuff that needs a serious overhaul, where do we stand on guests and not issuing them with sessions?
I personally think the benefits drastically outweigh the downside but I'm thinking others may feel differently. Anyone got any objections to what I'm suggesting?
I personally think the benefits drastically outweigh the downside but I'm thinking others may feel differently. Anyone got any objections to what I'm suggesting?
Nao
- Dadman with a boy
-
-
- Posts: 16,082
So, putting aside the friend stuff that needs a serious overhaul, where do we stand on guests and not issuing them with sessions?
Ideally, we would issue sessions for guests that allow for cookies. Meaning that they'll never get a session started on first visit, but if we (still) attempt to set a cookie, the next page they view will then start a session, so they should be able to log in, right...?
Now there's the issue of mobile detection. Perhaps we could use my quick class for guests without sessions, and the more complete (and slower) class for everyone else... I dunno. It feels kinda hackish.
I'm also still bothered by the fact that you don't seem excited about associating IPs with sessions so that guests without cookies could at least be tracked... :P
I personally think the benefits drastically outweigh the downside but I'm thinking others may feel differently. Anyone got any objections to what I'm suggesting?
Arantor
-
-
- As powerful as possible, as complex as necessary.
- Posts: 14,278
I'm also still bothered by the fact that you don't seem excited about associating IPs with sessions so that guests without cookies could at least be tracked...
Maybe when IPv6 is widespread and everyone's using it we can reconsider it but there are so many foibles attached to using IP as 'detection' that it's unreal.
* there are still users shuffled behind a massive network so that they have different IPs over time, sometimes per page, though this is distinctly less common than it used to be.
* users behind any kind of proxy will be lumped together under fewer IPs, meaning that for example the one forum I work on will only ever show 1 guest because of way requests are routed to it behind the firewall, it only ever sees 10.0.0.2 as the incoming IP address. EVER. Kind of renders everything else moot for that user.
* it still treats different Google (+Bing+Baidu) bots as separate users.
* spammers can and will inflate this artificially.
* mobile users are still likely to be incorrect, especially if they happen to be on the move between cell towers, again it's routed through a proxy, though a much larger one.
IP != identification of any kind.
Ideally, we would issue sessions for guests that allow for cookies. Meaning that they'll never get a session started on first visit, but if we (still) attempt to set a cookie, the next page they view will then start a session, so they should be able to log in, right...?
As far as handling failed logins and preventing more than 3, that would have to be done in a session but there's no reason we need to start sessions all the time for every user/guest/wandering monkey, which is where I'm going with this.
Though, disregard the whole cookie aspect. For the purposes of what I'm suggesting, the fact that cookies are used is almost irrelevant; the fact we're doing sessions at all for guests outside of logging in is a massive amount of per-request overhead that I don't think we need to handle since all we're actually doing in those cases is analytical stuff and vague storage.
What, exactly, do we need to store in the session regarding mobile detection?