Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0005969opensim[GRID] User Servicepublic2012-04-17 09:342019-02-04 10:13
ReporterRobert Adams 
Assigned To 
PrioritynormalSeveritymajorReproducibilityalways
StatusnewResolutionopen 
PlatformOSOS Version
Product Versionmaster (dev code) 
Target Versionmaster (dev code)Fixed in Version 
Summary0005969: Possible to log into a grid multiple times as same identity
DescriptionCan log into the same grid multiple times as the same identity if logging into different simulators of that grid.
Steps To ReproduceOpen a viewer and log into OSGrid/Lbsa Plaza as some user. Open another viewer and log into OSGrid/Wright Plaza as the same user. You can move around in both simulators. Haven't tried chatting to myself.

Teleporting the Wright Plaza user to Lbsa Plaza causes the Lbsa Plaza person to log out and Imprudence of the teleporting person crashes.
TagsNo tags attached.
Git Revision or version number2254a718c83df18746be1c9ccfad48928eb48cb3
Run Mode Grid (Multiple Regions per Sim)
Physics EngineODE
EnvironmentUnknown
Mono VersionNone
ViewerImprudence and FireStorm
Attached Files

- Relationships
related to 0006594new Users can log in multiple times 

-  Notes
(0021257)
smxy (reporter)
2012-04-17 10:04

This is by design and is not a bug. As long as your root or child agents, of each instance of yourself, do not overlap, then all is fine. If they overlap, there will, understandably, be issues - one or both will get disconnected.
(0021260)
justincc (administrator)
2012-04-17 16:51

AFAIK this really isn't by design. It should only be possible to log your user once onto a grid.
(0021261)
smxy (reporter)
2012-04-17 20:01

I'm pretty sure that if you check with Melanie, you'll find that it is by design.
(0021262)
Diva (administrator)
2012-04-17 20:12

Yes, this is by design. I thought that someone at some point had broken this, but it's really needed in some cases. Maybe not in the SL scenario, but many other use cases. So if this is still working, great! And if someone wants to restrict it to one session per account, please use a config var, because I am working on applications that need multiple sessions per account.
(0021268)
justincc (administrator)
2012-04-18 16:01

I'm curious as to what kind of use cases need this? It seems to me that multiple simultaneous logins by the same user is a rich source of potential bugs.
(0022823)
Loralai (reporter)
2012-10-09 14:10

I have to agree with justincc on this, it can open up a nice pot of new bugs that may cause some severe issues. To be honest there is one security issue I can think of that would be caused by this. Someone gaining access to another persons account on some grid out there and logging on at the same time. One of the things many people look for is an account compromise when they get logged out of a grid without internet or grid host isssues
(0022831)
melanie (administrator)
2012-10-10 21:56

This is indeed intentional. There is a config for it to determine whether or not the login server allows it. If set, multiple logins are possible. This can be used, for instance, to log a teacher into several identical sims with one group of students each as a measure for scaling.
(0022834)
justincc (administrator)
2012-10-12 17:18

The problem is that other parts of OpenSimulator, such as the GridUser service, do not account for this config option properly - the first logout would register the user as entirely logged out.

Properly handling this would increase system complexity and I can't currently see that the gain is worthwhile.
(0022836)
melanie (administrator)
2012-10-12 17:24

Sorta wrong. The system is designed to allow multiple entities to authenticate and use services. The system allows multiple presences if configured to do so. This already fully works. The part that doesn't work is the GridUser field LoggedIn. It's a relic and never been removed although it should have been. It's based on only one login being possible and that is just not how robust works.
(0023390)
wbalazic (reporter)
2013-01-07 06:56
edited on: 2013-01-07 06:57

Incidentally, this "feature" will crash a region if the avatar logs in twice. Given the unpredictable nature of Presence if your viewer crashes and Presence on the grid decides you are actually still there and you log back in (which this feature allows) it will crash the region. This is re creatable 100% of the time.

(0023391)
melanie (administrator)
2013-01-07 07:47

The feature exists for specialized applications. It has failure scenarios if not used properly. That is known. Enable at your own risk.
(0023393)
justincc (administrator)
2013-01-08 17:45

The fact is that this is effecitively default behaviour. If it causes crashing and other unexpected events then it should become the option once a configuration flag can be put in place.

Even then, if it actually crashes on relog then it doesn't sound usable for anybody.
(0023394)
melanie (administrator)
2013-01-08 17:48

I believe not allowing it IS default behavior. Also, it doesn't crash on relog, it crashes when the same avatar tries to enter a sim again, e.g. A walking into a sim where B is already there. The classroom scenario is one where it is understood that teachers do not meet themselves because they know not to try.
(0023395)
wbalazic (reporter)
2013-01-08 21:15
edited on: 2013-01-08 21:17

"Allowing it" IS the default behavior. We have looked to verify (verified via the OSGrid Robust by Hiro Protaganist, and on LFGrid by Ashton Nobilis), and by default, it ALLOWS this. If this is some very specific thing for "specialized applications" that should be "enabled at own risk" it should be DISABLED by default not enabled. With regard to the "it crashes when the same avatar tries to enter the sim again"... the problem with this is, until presence works effectively (which it doesn't currently) frequently it thinks an avatar is there after it has logged out (or the viewer has crashed) and when the person re-logs, presence now thinks they are logged in twice, and it stops the sim from allowing anyone to log into it until it is forced closed and restarted. We can recreate this scenario at will.

(0023412)
Emperor (reporter)
2013-01-15 22:19

Well okay then I am not seeing things here with being logged in same avi on two seperate pcs. Imagine my shock when i accidently logged the same avi in when testing an idea i had to get rid of the 256x256 barrier.

This is actually not a very good idea to allow multiple logins of the same avi. Especially when in grid mode. This does create some security vulnerabilities and would also put users at risk to having content stolen and opens them up to a whole can of worms regarding complaints.

It probably does have some good merits but I don't think id be to quick to implement this until the vulnerabilities are found and fixed.
(0034114)
tampa (reporter)
2019-02-04 10:13

All references of allowDuplicatePresences have a hardcoded default of false, standard configuration does not mention the availability of this variable and does not set them, thus default, unless otherwise configured, it is set to false.

The configuration for multiple presences for usecases as described above is thus still possible, if the variable AllowDuplicatePresences is set as true.

Whether or not this usecase is still supported or working fully I have not tested, but if someone finds an issue with it, it should go into a new ticket at this point.

Presence, more specifically, robust is a "dumb" service that simply provides a masterserver-like registry of variables across a grid, it does not clean after itself in many ways, there are tickets about this too, but clearing out stale presences is as simple a matter of removing the line in the database. This can be done simply by allowing each user removal of their own presence in the database(DELETE WHERE UUID MATCH) and in some cases checking for nullkey in the regionid field(although be careful it may be nullkey during teleports).

- Issue History
Date Modified Username Field Change
2012-04-17 09:34 Robert Adams New Issue
2012-04-17 10:04 smxy Note Added: 0021257
2012-04-17 16:51 justincc Note Added: 0021260
2012-04-17 20:01 smxy Note Added: 0021261
2012-04-17 20:12 Diva Note Added: 0021262
2012-04-18 16:01 justincc Note Added: 0021268
2012-10-09 14:10 Loralai Note Added: 0022823
2012-10-10 21:56 melanie Note Added: 0022831
2012-10-12 17:18 justincc Note Added: 0022834
2012-10-12 17:24 melanie Note Added: 0022836
2013-01-07 06:56 wbalazic Note Added: 0023390
2013-01-07 06:57 wbalazic Note Edited: 0023390 View Revisions
2013-01-07 07:47 melanie Note Added: 0023391
2013-01-08 17:45 justincc Note Added: 0023393
2013-01-08 17:48 melanie Note Added: 0023394
2013-01-08 21:15 wbalazic Note Added: 0023395
2013-01-08 21:17 wbalazic Note Edited: 0023395 View Revisions
2013-01-15 22:19 Emperor Note Added: 0023412
2013-06-15 09:13 dz Relationship added related to 0006594
2019-02-04 10:13 tampa Note Added: 0034114


Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker