Forum OpenACS Development: ]project-open[ Patches for OpenACS 5.9

Hi!

There are some patches in the OpenACS “core” (acs-* packages) that we have performed in the last years and that might be interesting for the next OpenACS release.

Also, we have implemented a number of features and will implement a few new features that would belong more the the OpenACs kernel than to ]po[. I would be glad to hear an opinion on that it they are worth being considered for including:

OpenACS Security:

- acs-subsite/www/register/account-message.tcl line 6: XSS security issue: "message:allhtml" allows for JavaScript injection. Please replace with "html", which works perfectly.

OACS-5-7 Patches:

- /acs-service-contract/tcl/acs-service-contract-init.tcl line 14: Added a catch-error around the "acs_sc_proc $impl_contract_name ..." command. This catch allows for reasonable debugging after somebody has messed up the configuration. Otherwise OpenACS won't even start up.

- /acs-tcl/tcl/00-database-procs.tcl: Patches for Windows: Windows doesn't support Unix sockets. In the IF statements "if { $tcl_platform(platform) eq "windows" }" please add the line 'set pghost "-h [db_get_dbhost]"' in order to force a TCP/IP connection.

- /acs-tcl/tcl/community-core-procs-postgresql.xql line 125: We modified the line to be: ' and (lower(username) = lower(:username) OR lower(email) = lower(:username))' in order to allow users to log-in using either their Email or their Username. Username and email are clearly distinct, so there is no negative impact.

- /acs-tcl/tcl/community-core-procs.xql line 7, 15, 121 and 174: Configuration mess-up protection: We've added a min(...) to the 'select user_id ...' because the users has a unique constraint on screen_name, while the query includes a "lower(...)" and therefore may return multiple results, which is the case after importing users from some f...ed corporate Active Directory LDAP servers. There have actually been several cases of this...

- /acs-tcl/tcl/community-core-procs.xql line 121: Again we allow for login with email or username with: '(lower(username) = lower(:username) OR lower(email) = lower(:username)) and'

New Features Implemented:

- Automatic Localization Review: /acs-lang/tcl/lang-message-procs.tcl: We have modified the translation process, so that modified localization strings are sent to a "localization server" if the user accepts. At the server side, we insert updated translation as lang_messages_audit comments to existing strings. This way we can find out which translations are candidates for revisions. The entire functionality consists of only 100 lines of code including client and server functionality.

New Features Planned:

- "App Store" or "App Marketplace": This relates somehow to the improved "install from repository" option in OpenACs 5.8.0b2: We plan to release some packages under licenses other than "GPL V2 or higher" (GPL V3 for Sencha Ext-JS and proprietary extension packages). So we plan to extend/beautify the OpenACs Package Manager. This development obviously should be part of OpenACS Core and not ]po[. Any suggestions?

- “Atlassian Confluence” Type Configuration of OpenACS: We can now integrate ]po[ "portlets" into XoWiki, so we consider to include a Confluence like configuration of OpenACs in the next version of ]po[, so that users can have their own space writing blogs etc., subsites for specific working groups, and all that integrated with the "hard PM" of ]po[.

- Use of Sencha Ext-JS and "proceeding on the path of independence" from AOLserver/NSD: We have pretty much committed to use www.sencha.com stuff in ]po[ V4.1, in line my posting about the long-term ]po[ strategy (https://openacs.org/forums/message-view?message_id=3637561). Most or all Sencha stuff will be based on the ]po[ REST interface and should be independent from AOLserver/NSD, which could allow us to release sub-applications in the future (for example a mobile Web application or a Basecamp style simplified PM system) that would run on a LAPP (LAMP with PostgreSQL instead of MySQL) stack.

Collapse
Posted by Antonio Pisano on
Regarding your last point, if you really think the right way is independence from Aolserver/Naviserver, a good approach could be to switch most of your API development to the database PL/SQL.

Such style of development is already well established for OpenAcs and would keep you mostly free from the webserver while still being benefical to this community.

Collapse
Posted by Gustaf Neumann on
The first three changes are clear improvements and are incorporated already in the oacs-5-8 branch.

Are there arguments against allowing username or email address in the login field (proposed changed 4 and 6)?

concerning proposed change 5 ("lower" weakens constraint on screen_name, email, etc): It seems to me as if the datamodel of ]po[ misses some constraints: parties has a "lower" constraint for email (parties_email_lower_idx), users has a lower constraint for screenname and username (users_screenname_lower_idx, users_username_lower_idx), so everything should be ok and no change is needed for OpenACS...

Collapse
Posted by Gustaf Neumann on
... minor correction: these are indices and no unique constraints (just users_screen_name_un and parties_email_un). so probably, the unique constains should be added.