Instead of checking if password is null, wouldn't you just want to distinguish whether or not authentication was successful or not (would handle null password as well as incorrect credentials)?
-Burke On Wed, Apr 11, 2012 at 11:50 AM, Darius Jazayeri <[email protected]>wrote: > I'm just glancing at the code... > > Reporting does this: > > AdministrationService adminService = Context.getAdministrationService(); > String userName = adminService.getGlobalProperty(SchedulerConstants. > SCHEDULER_USERNAME_PROPERTY); > String password = adminService.getGlobalProperty(SchedulerConstants. > SCHEDULER_PASSWORD_PROPERTY); > Context.authenticate(userName, password); > The quickest fix would be to just *not* call Context.authenticate if the > password GP is not set, and do a log.warn instead. This would mean that you > could safely set up OpenMRS, though reporting's scheduled tasks won't start > working until you set the GPs. (And if you type the password wrong in the > GP, or you change the user's password without changing the GP, the bug Mark > mentioned will recur.) > > Does that sound okay as a quick fix to unblock 1.9? > > The "correct" fix requires figuring out how to have AbstractReportTask > (which isn't an OpenMRS scheduled task) be run as Daemon in 1.7+. > > -Darius > > On Tue, Apr 10, 2012 at 7:03 PM, Darius Jazayeri > <[email protected]>wrote: > >> Burke, FYI, the Reporting and Logic modules both are written against >> OpenMRS 1.6, whereas Daemon wasn't introduced until 1.7. >> >> Logic already has some ugly reflection code to try using the Daemon to >> run its scheduled task, and otherwise falls back to proxy privileges, or >> something like that. I think Reporting needs something similar. >> >> Once we actually stop supporting OpenMRS 1.6, writing modules will get >> easier, with respect to this, and also the improved activator interface. >> >> -Darius >> >> >> On Tue, Apr 10, 2012 at 6:34 PM, Burke Mamlin <[email protected]>wrote: >> >>> Reporting should not be able to run something as Daemon; in fact, it >>> should be impossible to authenticate as the daemon user. Rather, daemon >>> threads can only be created by Daemon and it will only start those things >>> that it knows about. Logic was known by Daemon because it was part of >>> core. As logic moves out of core, we'll need to come up with another >>> mechanism for Daemon to know about it (and reporting). >>> >>> One such mechanism is schedule tasks. We trust that only admins (e.g., >>> admins installing a module) can add a scheduled task; therefore, one of the >>> things Daemon knows how to do is to start an existing scheduled task. >>> >>> If you don't want to be limited to scheduled tasks, we could do >>> something similar for modules – e.g., define a method for OpenMRS modules >>> (within the module interface) that Daemon would know about and could invoke >>> on a daemon thread. Alternatively, you could start your processes during >>> module startup by spawning another daemon thread (daemon threads, like the >>> thread used for module startup, should be able to ask Daemon to spawn >>> another daemon thread). >>> >>> -Burke >>> >>> >>> On Tue, Apr 10, 2012 at 8:40 PM, Michael Seaton <[email protected]> wrote: >>> >>>> ** >>>> I think we probably need to fix reporting to do what Ben said Logic is >>>> doing. However, if the OpenMRS scheduler benefits from use of the Daemon >>>> user "for free" in 1.7+, we'll likely need to explicitly tell reporting to >>>> use the Daemon user for the Spring-managed scheduled tasks. Unfortunately, >>>> we're in a reporting sprint right now, so we're not in the ideal position >>>> to patch reporting to work with 1.9... >>>> >>>> Mike >>>> >>>> >>>> >>>> On 04/10/2012 08:14 PM, Darius Jazayeri wrote: >>>> >>>> So what's the implication for what we should do with 1.9? >>>> >>>> Is it a fix to 1.9.x to include the right reporting version? >>>> Is it a fix to reporting to avoid running the tasks if it doesn't have >>>> a username/password? >>>> >>>> -Darius >>>> >>>> On Tue, Apr 10, 2012 at 4: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 >>>>> >>>> >>>> ------------------------------ >>>> 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]
