aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/OpenSim/ApplicationPlugins/CreateCommsManager (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Adds session authentication upon NewUserConnections. Adds user key ↵diva2009-04-141-5/+5
| | | | authentication (in safemode only) upon CreateChildAgents. All of this for Hypergrid users too. This addresses assorted spoofing vulnerabilities.
* Another bit of refactoring to try to make sense of ↵diva2009-03-291-1/+2
| | | | OpenSim.Framework.Communications. Everything that looks like a service, with service handlers, moved to .Services -- i.e. LoginService and Response, and GridInfoService. The rest of the changes were to adapt to the new locations of those files.
* * De-duplicated login service some morelbsa712009-03-201-19/+0
| | | | | | * Normalized m_inventoryService * Pulled AddActiveGestures up
* * Cleanup and CCC (Code Convention Conformance)lbsa712009-03-101-21/+21
|
* Added a output message to CreateCommsManagerPlugin for when a user tries to ↵MW2009-03-061-36/+46
| | | | run with both -hypergrid=true and -background=true command line arguments. As these two don't work together as they initialise different root OpenSim classes. I was going to change it back to the old behaviour where in that usecase it would just startup in the background but without hyerpgrid enabled. But think its better to give a error about this and then exit, so the user knows to change their settings. Rather than later wondering why hypergrid isn't working.
* Moved Linden protocol login handling to modules in OpenSim.Client.Linden. ↵MW2009-03-031-17/+16
| | | | | | | | There are two region modules in there LLStandaloneLoginModule (for standalone mode) and LLProxyLoginModule (for grid mode which just handles incoming expect_user and logoff_user messages from the remote login server) Changed OpenSim.Framework.Communications.Tests.LoginServiceTests to use the LLStandaloneLoginService (from the LLStandaloneLoginModule) rather than LocalLoginService. Really these login tests should most likely be somewhere else as they are testing specific implementations of login services. Commented out the old LocalLoginService as its no longer used, but want to check there are no problems before it gets deleted.
* Refactoring of CreateCommsManagerPlugin.MW2009-03-031-32/+28
| | | | | Plus some general cleanup of a few other files (deleting excess blank lines etc)
* Added more error info to CreateCommsManagerPlugin.MW2009-03-021-0/+1
|
* Added some debug output to CreateCommsManagerPluginMW2009-03-021-1/+11
|
* Changed the CreateCommsManagerPlugin so it requests a IRegionCreator and ↵MW2009-02-271-4/+3
| | | | | | | subscribes to the OnNewRegionCreated event on that interface rather than requesting the LoadRegionsPlugin directly. Removed the reference to OpenSim.ApplicationPlugins.LoadRegions from the CreateCommsManagerPlugin project.
* svn attribute fixes so that we can play nice between windows and linuxSean Dague2009-02-262-267/+267
|
* Added IRegionCreator interface that all ApplicationPlugins that are creators ↵MW2009-02-261-0/+1
| | | | | | | of Scenes should implement and register with the ApplicationRegistry.StackModuleInterface<>(); So that other plugins can attach to their OnNewRegionCreated event. Made some changes to IRegistryCore and RegistryCore so they support "Stacked" interfaces.
* Another change to how the CreateCommsManagerPlugin checks if it should be ↵MW2009-02-261-1/+2
| | | | creating HG or normal CommunicationsManager.
* Changed CreateCommsManagerPlugin so it handles external subclasses of ↵MW2009-02-261-9/+10
| | | | | | | OpenSimBase. This process of checking if it should be creating HG or normal CommunicationsManager needs to change. So look out for a revert of this whole plugin soon.
* Moved the Initialisation of the CommunicationsManager to a ApplicationPlugin. MW2009-02-262-0/+264
Also in that plugin it registers the IUserService with all the Scenes (as they are created). So now we can start changing over all uses of IUserService, that currently access it from the CommunicationsManager to accessing it from the Scene.RequestModuleInterface call. Once that is done we can move the UserService creation out to its own plugin and remove all references to it from the CommunicationsManager. Then we can take the next CommunicationsManager interface and repeat.