Sharing users among systems
One of the issues that arose during the integration process was how to maintain user identity when integrating between different systems. During the exercise, data was moved around anonymously, without having more than a display name describing an item’s author; but for real world behaviour this is unacceptable.
Therefore one of the many points (I cannot emphasize enough the word many here) that were left for work after the exercise was researching on a way to seamlessly allow users to use the different applications without requiring a long and tedious process. During a crisis, there is no time to get an account on three or four different systems and after that, configure them so each knows what your username is on the other ones.
Nevertheless, the possibility of using a standard such as OAuth for sharing data for those users already on the userbase of all systems is not discarded. For cases when users have been using one or many of the systems, allowing them to get an authorization token on one application to grant usage for another one, is a great feature to be implemented. It is also a common standard so whenever any other application wants to join the mashup, it should be as easy as possible.
Another option that came up was using a common user base for all systems, such as OpenID. This way a user would only have to create an account on a single server (any open id provider of choice) and use that ID to login at any of the servers, therefore the identity of a user is shared along all systems without requiring any configuration.
The main drawback of this last option is that it requires access to the OpenID provider, something that is not always available on disaster scenarios. Among the features that were considered important to react during a crisis were both portability and the ability to work offline, both out of the network and within an internal network disconnected from the Internet. Using a user base on the cloud would not benefit this goal at all.
Therefore one of the tasks for these weeks is envisioning a robust standard login method for all applications that allows integration among systems as seamless as possible. User startup time during a crisis must be reduced as much as possible, while still retaining all the security features necessary to maintain the required standards to protect user’s privacy.
User32.dll deleted by AVG8
Last night I was a victim of the AVG8 bug that marked User32.dll as a trojan (just a false positive). What annoys me the most is not the bug per se, but the fact that AVG Heal option simply deleted the file without any warning or simply backuping it (just a “may lead to system inestability”), and that WXP just let him do it. Damn, it’s a system file!
Anyway, I’ve just found a blog with a good solution for those who keep a WXP CD next to their PC “just in case”:
When AVG have performed the same action on your PC, cleaning/removing user32.dll, reboot your PC with the Windows XP CD, hit in the upcoming menu the “R” on your keyboard, hit “1″, hit “enter”, answer password question with “enter” on your keyboard, after that you get the command prompt c:\windows>
Type behind that prompt
copy c:\windows\$NTuninstallKB925902$\user32.dll c:\windows\system32
and hit “enter” on your keyboard.
Hope it works!
Update: It worked, mi home PC is back online! As a side note, there were several NTUninstall directories newer than 925902, although I didn’t check all of them for a User32.dll, but maybe it could be possible to rollback to a newer User32. Anyway, since this one worked flawlessly, I’m not digging any more in the matter.