Zend Module Installer

OpenEMR Development
#1

zhhealthcare wrote on Saturday, December 28, 2013:

Hi,

We have developed a zend based module installer for OpenEMR which enables the community an option to install enhancements as compartmentalized code in order to help maintain and manage
installations. Thus enabling contributors to release features as modules from which the user
can opt to use without hindering the basic structure and direction of the common
project.

The git hub and sourceforge path are as follows. The complete documentation is available in sourceforge link.

Sourceforge path : https://sourceforge.net/p/openemr/code-review/232/
Github path : Commits · zhhealthcare/openemr · GitHub

Please share your comments/suggestions.

Thanks and Regards,
ZH Healthcare

My First Zend Module Build... Need Help
#2

bradymiller wrote on Wednesday, January 01, 2014:

Hi,

To get Zend to work in Ubuntu, I had to do the following:
1.Edit /etc/apache2/sites-available/default:
Change:
AllowOverride None
To:
AllowOverride FileInfo

2.Then enable mod_rewrite:
sudo a2enmod rewrite

3.Ensure using php version 5.3.3 or greater

-brady
OpenEMR

Trouble with modules
#3

yehster wrote on Wednesday, January 01, 2014:

I have lots of concerns about including zend on multiple fronts.
Prime on my list are security and audit logging.

There are queries which don’t use the standard OpenEMR conventions

#4

zhhealthcare wrote on Wednesday, January 01, 2014:

Kevin,
In this zend module we have implemented all the security mechanism which are available in the community version. Also we have implemented the logging mechanism which will log all the db queries in to the same log table.
And also I think its the time to move to framework based openemr. So that we can avoid all the security vulnerability and the data vulnerability. Also I strongly believe that zf2 is one among the best framework.

HAPPY NEW YEAR
Thanks and Regards,
ZH Healthcare

#5

yehster wrote on Wednesday, January 01, 2014:

Please provide more documentation regarding your approach to security. This is a huge bit of code to review.

The “AllowOveride:FileInfo” setting Brady mentions in needing to get things to work is also a significant concern.

My other big concern is that Shameem during the Ad-hoc conferences expressed the fact that his goal for this module installer is to allow for easier integration of closed sourced modules. This is not a “vendor-neutral” contribution.

#6

zhhealthcare wrote on Wednesday, January 01, 2014:

““Free software” means software that respects users’ freedom and community.
Roughly, the users have the freedom to run, copy, distribute, study,
change and improve the software. Thus, “free software” is a matter of
liberty, not price.” http://www.gnu.org/philosophy/free-sw.html

My goal is to provide the users of OpenEMR the liberty to accept and use
closed or open source modules. As an open source community we have the
ability to accept only open source modules, but we do not have the right to
block the users ability to accept closed source modules.

This is no different from the forms installer which is already part of
OpenEMR. There are people who sell the forms they have created, and yet
there are others who contribute forms to open source.The argument that this
is not Vendor Neutral is not right. Any Vendor can develop a module, open
or closed source, and distribute it the way he or she wants it. The rules
and framework to develop a module are open to any and everyone. My view is
that this will actually increase interest in our community. I have stated,
time and again, the example of the Lab module where there are several
vendors developing interfaces. Ultimately the best interface with the
right price will attract users. So also is the case of the eRx.

ultimately I leave it to the community to decide if they want a module
installer where anyone can develop modules and contribute it to the
community.

–
Shameem C Hameed
ZH Healthcare
2010 Corporate Ridge, Suite 700
McLean VA 22102

ph: +1-703-340-8065 Ext: 6666
Direct: 571-766-8074
Fax: +1-703-890-8702


http://www.linkedin.com/pub/shameem-hameed/5/5a6/712

#7

mdsupport wrote on Wednesday, January 01, 2014:

Congratulation to ZH for committing resources towards a change - something that has been discussed on these forums for long time.

Some basic questions - probably already discussed elsewhere…

Shouldn’t framework be implemented at a lower level than (one of the) application using it? Isn’t it a framework for PHP not OpenEMR? By putting Zend code inside

interface/modules/zend_modules/library/Zend/

is OpenEMR taking on responsibility of releasing Zend patches as part of OpenEMR patch/upgrade process?

This also makes it harder for an installation to use other modules unrelated to OpenEMR.

Is it too late to suggest that implementation process to be :

Step 1. Working OpenEMR

Optional Steps:
Step 2. Install Zend per Zend install process
Step 3. Activate zf2 based modules using options/configuration

This will let community evaluate the benefits until consensus emerges to make OpenEMR a zf module.

#8

sunsetsystems wrote on Thursday, January 02, 2014:

We’ve had this discussion before:

https://sourceforge.net/p/openemr/discussion/202506/thread/94801241

I don’t see how it can be right to include Zend in our project. It’s a separate project that is readily available for installation and comes with all major Linux distributions. We don’t want to be responsible for keeping it up to date. Furthermore we are very far from any consensus to standardize on using it.

In general I think it’s probably OK for some individual contributions to use Zend, as long as anything requiring it is an optional feature that can be disabled. However as things are now I’d discourage it (see various comments in the thread referenced above).

What I do encourage is more use of object oriented methods, especially to encapsulate things like patients, encounters, providers, facilities etc. A lot of the stuff in the library directory could be rewritten to use classes. We could clean things up a lot that way without doing anything controversial, and if we ever do settle on a framework it would make moving to it easier.

Rod
http://www.sunsetsystems.com/

#9

zhhealthcare wrote on Thursday, January 02, 2014:

Hi,

We have attached a document regarding the security mechanisms.
We have not modified the zend library files, so it is possible to move it to another level, we will try it and let you know.

Thanks and Regards,
ZH Healthcare

#10

yehster wrote on Thursday, January 02, 2014:

We have not modified the zend library files, so it is possible to move it to another level, we will try it and let you know.
Changes when included zend skeleton application from git. · zhhealthcare/openemr@9b9da75 · GitHub

You have TONS of changes to Zend files here.

#11

yehster wrote on Thursday, January 02, 2014:

All that your “security” document seems to do is list vulnerabilities. It doesn’t say how they are addressed.

#12

zhhealthcare wrote on Friday, January 03, 2014:

Hi,

The commit you mentioned includes only the changes from the Zend git repository as a result of pulling the default skeleton application posted by Zend. The Zend library files are located in ‘/zend_modules/library’ folder, it is not affected by this commit. If you want to use the default zend library with module installer then we can use the third commit directly after which the zend library path must be specified in the configuration file. We will make the necessary changes and will commit it as soon as possible.

Thanks and Regards,
ZH Healthcare

#13

zhhealthcare wrote on Friday, January 03, 2014:

Hi,

As per the discussion we have made the commits in such a way that the user can use already existing zf2 library available in his system for the module installer. The path can be set in ‘zend_modules/init_autoloader.php’ file which is mentioned within the file comments.

The git path for the latest commit is : Sample module to test module installer. · zhhealthcare/openemr@5dde10c · GitHub

Thanks and Regards,
ZH Healthcare

#14

bradymiller wrote on Saturday, January 04, 2014:

Hi ZH,

Couple quick questions for now:

  1. Regarding your security document above, how do you plan to secure the following from sql injection:
    SELECT * FROM $variable_table_name WHERE ‘value’=? ORDER BY $variable_direction LIMIT $variable_limit
    (note there are functions within openemr database engine that do these things already)

  2. Are you able to insert a new sql row of data and correctly return the insert row id?

  3. Is your log function doing the same thing as the original log function in openemr?

thanks,
-brady
OpenEMR

#15

yehster wrote on Saturday, January 04, 2014:

I am also concerned about the potential for “social engineering” attacks should this installer be incorporated into the official code base.

A malicious attacker could offer a module under the guise of something useful. Given the wide variety of technical skills among OpenEMR users, I suspect a significant number would “fall for it.”

The expressed purpose of this module is make it easier to run “arbitrary code” in the context of OpenEMR, which is a dangerous prospect.

I’m trying to keep an open mind about the issues, but as Rod pointed out, we’ve discussed this topic pretty extensively before and I still don’t think this code is appropriate.

#16

bradymiller wrote on Saturday, January 04, 2014:

Hi Kevin,
Focus on keeping an open mind is good in this case. Regarding “social engineering” attack issue, already have that issue in the forms installer, which is a rather vital feature; if somebody downloaded and installed a “attack” form, such as CAMOS-WAMOS or something like that. As with the forms installer, should ensure only admin can add modules to cover this.
-brady

#17

yehster wrote on Saturday, January 04, 2014:

Except code for forms seems like it would be more natural to review before because the administrator has to take the move it into the forms directory manually first.

The “one touch” install process has “convenience vs. security” trade-offs.

Sometimes there’s value in slowing thing down/taking extra steps. Think “timeout” in the Operating Room.

#18

mdsupport wrote on Saturday, January 04, 2014:

Before pulling in code, when we do our preliminary checks we find no invoke for AuthenticationService or Permissions\Acl. Does that mean the modules are not expected to use zf2 core security mechanisms? Shouldn’t there be some code mapping/linking OpenEMR session with zf2 objects? Not sure if any suggestions could be offered if we are just checking to see if specific config changes allow zf2 based code to connect to MySQL.

On a related note, community will need to think about implications of external modules. If a practice is sold a ‘PayPal payment processing module’ by Xyz LLC, surely OpenEMR has no responsibility and that may be ok. But if Xyz LLC chooses to contribute a module, are there adequate number of reviewers with appropriate tools and skillsets up to the task? Traditional code review will not work to identify issues in million lines of code in hundreads of files generated by some IDE?

#19

zhhealthcare wrote on Monday, January 06, 2014:

I would humbly submit that we should let the users decide what they want to
run on their systems. Let us treat them as mature adults. If a user
decides to run arbitrary code it should be his choice and we shouldn’t be
policing that. That goes against the open source spirit.

i agree with “MD Support” in that we should police the code that is
submitted to us as a module. These should be thoroughly reviewed before
accepting as part of the community code. Why are we rejecting something
based on an apprehension that it has the potential to be used for bad?

–
Shameem C Hameed
ZH Healthcare
2010 Corporate Ridge, Suite 700
McLean VA 22102

ph: +1-703-340-8065 Ext: 6666
Direct: 571-766-8074
Fax: +1-703-890-8702


http://www.linkedin.com/pub/shameem-hameed/5/5a6/712

#20

yehster wrote on Monday, January 06, 2014:

Why are we rejecting something
based on an apprehension that it has the potential to be used for bad?

Because I am one of the few people who takes care of security issues for the project, I worry a great deal about the very real additional burdens of including such a large chunk of new code in the project.

There are many existing pieces of the project that have “the potential to be used for bad” that still need to be taken care of with our limited resource, and the cost/benefit trade-off for this particular feature does not seem worth the effort at the moment.