Sounds like something to bring to a design discussion. Running background processes is fine, but if they need to use the API, then Daemon needs to be taught about them (i.e., we need to devise a "secure" mechanism for Daemon to invoke/bless the threads without introducing a Daemon.doWhateverITellYou(Runnable) method, which – like a proxy privilege method – provides a single-step bypass for any level of security.
We can take some time on tomorrow's design call to plan a workaround for getting 1.9 functional again. -Burke On Tue, Apr 10, 2012 at 7:36 PM, Michael Seaton <[email protected]> wrote: > ** > One wrinkle is that we (I) moved these tasks in 1.7.1 such that they are > no longer scheduled tasks executed by the OpenMRS scheduler, but rather > tasks managed directly by Spring's built-in scheduling mechanism. The main > reason for making this change was that I didn't like how the OpenMRS > scheduler-based Scheduled Tasks hung around after the module was > un-installed and also because I was running into some Classloading issues. > With Spring-managed scheduled tasks, these issues disappear - the tasks are > run if the module is installed, and not run if it isn't. The main drawback > is that the end user can't start / stop / delete these tasks from within > the management pages, but these are not meant to be optional or > configurable - they are things the reporting module relies on working in a > specific way, so shouldn't be end-user modifiable. > > > On 04/10/2012 06:37 PM, Ben Wolfe wrote: > > The gps should not be set by openmrs after 1.7 the daemon user is used > instead. The reporting module should work like the logic module and only > authenticate if pre 1.7. > > I like the idea of clearing the scheduler gp, but that might mess up > modules like reporting that haven't updated to not use the authenticated > user. > > Isnt there an authenticate() method that should be called? Is that still > looking fur the scheduler username/pw in gps? > > Ben > On Apr 10, 2012 6:24 PM, "Darius Jazayeri" <[email protected]> > wrote: > >> Wyclif, >> >> That won't solve it--when you go through the setup wizard, you are >> required to enter a strong admin password ("test" is not allowed), so what >> Mark is describing is the issue that as soon as you've set up OpenMRS for >> the first time, you are guaranteed to have incorrect GP values for >> scheduler.username and scheduler.password. As a result, your admin account >> will soon be locked out, and it will stay that way forever due to the >> scheduled task. >> >> Options: >> >> 1. clear the scheduler.password property, and make sure that scheduled >> tasks don't try to run as admin if that isn't set >> >> 2. the setup wizard could set scheduler.password to the new admin >> password (but this is insecure) >> >> 3. change the reporting module to *not* use those GPs, but rather to >> use an anonymous user, but grant proxy privileges... >> >> -Darius >> >> On Tue, Apr 10, 2012 at 2:29 PM, Wyclif Luyima <[email protected]>wrote: >> >>> Are you running the standalone or are you using the 1.9 demo data from >>> the demo data downloads page? >>> >>> If yes to any of the above, I ran into this and i think the password >>> for admin was changed from *test*, try *Admin123*, we need to change >>> it back to *test* >>> >>> Wyclif >>> >>> >>> On Tue, Apr 10, 2012 at 4:55 PM, Mark Goodrich <[email protected]>wrote: >>> >>>> I’m having problems logging in to OpenMRS 1.9 after doing a clean >>>> install (as opposed to an update of an existing database). Has anyone else >>>> run into this issue? This is what I think might be happening: >>>> >>>> >>>> >>>> https://tickets.openmrs.org/browse/TRUNK-3272 >>>> ------------------------------ >>>> Click here to >>>> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >>>> OpenMRS Developers' mailing list >>> >>> >>> ------------------------------ >>> Click here to >>> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >>> OpenMRS Developers' mailing list >>> >> >> ------------------------------ >> Click here to >> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >> OpenMRS Developers' mailing list > > ------------------------------ > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > > ------------------------------ > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
