Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 421490

Summary: Changing login name can corrupt other users' data
Product: [ECD] Orion Reporter: Mark Macdonald <mamacdon>
Component: ServerAssignee: Anthony Hunter <ahunter.eclipse>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P3    
Version: 4.0   
Target Milestone: 6.0 M1   
Hardware: PC   
OS: Windows 7   
Whiteboard:

Description Mark Macdonald CLA 2013-11-11 17:39:09 EST
It is possible for a user to change their login name to another user's login name. The server allows this, and produces a freakish/corrupt hybrid of the two users' metadata, much the film "THE FLY" starring Jeff Goldblum.

0. Set up a server using orion.core.metastore=simple and orion.file.layout=userTree
1. Login as "mamacdon"
2. Go to Settings > User Profile, and use the DOM editor to remove the "readonly" attribute from the user name field.
3. Change the user name field to an existing user's id, "skaegi".
4. Click Update -- the change succeeds.

At this point both users have corrupt data. e.g.:

* For every project of mamacdon's, the project's .json file contains references to skaegi in the ContentLocation and WorkspaceId fields:
> "ContentLocation": "file:/www/whatever/serverworkspace/sk/skaegi/OrionContent/projectName",
> "WorkspaceId": "skaegi-OrionContent"
* skaegi's workspace.json has its ProjectNames overwritten by mamacdon's Project Names.
* skaegi's workspace.json has its UserId set to "mamacdon" (not sure about this one -- can't remember)
* There may also have been corruption in skaegi's user.json, but I can't recall the details.

We should disallow the change of login name when the given login name is taken (or disallow changing the login name entirely-- although I think it's a handy feature, others are opposed).
Comment 1 Mark Macdonald CLA 2013-11-12 09:20:38 EST

*** This bug has been marked as a duplicate of bug 421535 ***
Comment 2 Anthony Hunter CLA 2013-11-13 16:14:17 EST
I am reopening this defect. Even though you hacked the DOM, the request should not have been succeeded server side and you should have been given an error back. This is a separate issue from bug 421535.
Comment 3 Anthony Hunter CLA 2014-03-03 11:43:02 EST
This is fixed with the changes delivered with Bug 421535 .