Galen Charlton [Wed, 3 Jun 2015 17:42:06 +0000 (17:42 +0000)]
LP#1461625: ensure srfsh doesn't close STDOUT prematurely
Ensure that when running srfsh in non-interactive mode
that reads commands directly from a file, (i.e.,
"srfsh script.srfsh" or as a shebang script), it does
not close STDOUT after handling the first request.
To test
-------
[1] Create a srfsh script containing:
[2] Run "srfsh script.srfsh". Note that only the
results of the first echo request are output.
[3] Apply the patch and recompile, then run
"srfsh script.srfsh" again. This time, the
output of both requests is displayed.
Signed-off-by: Galen Charlton <gmc@esilibrary.com> Signed-off-by: Mike Rylander <mrylander@gmail.com>
Galen Charlton [Tue, 24 Mar 2015 21:00:57 +0000 (21:00 +0000)]
LP#1436047: make srfsh --safe act as if "! command" doesn't exist
This patch make srfsh treat attempting to run an external
command via "! command" as a parsing error if --safe is
supplied. It also suppress mention of "! commands" from
the internal help.
Signed-off-by: Galen Charlton <gmc@esilibrary.com> Signed-off-by: Mike Rylander <mrylander@gmail.com>
Mike Rylander [Tue, 24 Mar 2015 20:22:16 +0000 (16:22 -0400)]
LP#1436047: Allow disabling of "bang commands" in srfsh
srfsh has the ability to execute commands via system() calls using
the common "!command" syntax. This is very useful, but it would
be nice to be able to turn that functionality off in some cases.
This branch adds argument parsing to detect a new '--safe' command
line parameter, which disables the "!command" syntax.
Signed-off-by: Mike Rylander <mrylander@gmail.com> Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Galen Charlton [Tue, 24 Mar 2015 21:00:57 +0000 (21:00 +0000)]
LP#1436047: make srfsh --safe act as if "! command" doesn't exist
This patch make srfsh treat attempting to run an external
command via "! command" as a parsing error if --safe is
supplied. It also suppress mention of "! commands" from
the internal help.
Signed-off-by: Galen Charlton <gmc@esilibrary.com> Signed-off-by: Mike Rylander <mrylander@gmail.com>
Mike Rylander [Tue, 24 Mar 2015 20:22:16 +0000 (16:22 -0400)]
LP#1436047: Allow disabling of "bang commands" in srfsh
srfsh has the ability to execute commands via system() calls using
the common "!command" syntax. This is very useful, but it would
be nice to be able to turn that functionality off in some cases.
This branch adds argument parsing to detect a new '--safe' command
line parameter, which disables the "!command" syntax.
Signed-off-by: Mike Rylander <mrylander@gmail.com> Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Avoid referencing variable defined somewhere outside the send_ws()
function. Doing so happened to result in re-sending the same message
twice in some cases.
Signed-off-by: Bill Erickson <berickxx@gmail.com> Signed-off-by: Mike Rylander <mrylander@gmail.com>
Avoid referencing variable defined somewhere outside the send_ws()
function. Doing so happened to result in re-sending the same message
twice in some cases.
Signed-off-by: Bill Erickson <berickxx@gmail.com> Signed-off-by: Mike Rylander <mrylander@gmail.com>
Ben Shum [Mon, 10 Nov 2014 17:20:31 +0000 (12:20 -0500)]
LP#1391248: Fix NameVirtualHost warnings in websockets apache2.conf
For the websockets configuration, the sample apache2.conf for Apache 2.4 (i.e.
Ubuntu 14.04, etc.) contains NameVirtualHost entries that are no longer
needed.
When starting apache2-websockets, you may see warnings like:
AH00548: NameVirtualHost has no effect and will be removed in the next
release /etc/apache2-websockets/apache2.conf:53
Remove the NameVirtualHost entries and these warnings go away.
Signed-off-by: Ben Shum <bshum@biblio.org> Signed-off-by: Bill Erickson <berickxx@gmail.com>
Ben Shum [Mon, 10 Nov 2014 17:20:31 +0000 (12:20 -0500)]
LP#1391248: Fix NameVirtualHost warnings in websockets apache2.conf
For the websockets configuration, the sample apache2.conf for Apache 2.4 (i.e.
Ubuntu 14.04, etc.) contains NameVirtualHost entries that are no longer
needed.
When starting apache2-websockets, you may see warnings like:
AH00548: NameVirtualHost has no effect and will be removed in the next
release /etc/apache2-websockets/apache2.conf:53
Remove the NameVirtualHost entries and these warnings go away.
Signed-off-by: Ben Shum <bshum@biblio.org> Signed-off-by: Bill Erickson <berickxx@gmail.com>
Ben Shum [Sat, 13 Sep 2014 22:23:46 +0000 (18:23 -0400)]
LP#1369169: Mention the requirement for valid SSL certificate
The apache2-websockets instance will not start without a valid SSL certificate
in /etc/apache2/ssl. Include a mention of this in the README with the extra
stipulation that it is still possible to use a self-signed SSL certificate for
testing purposes, but this is not recommended for live installations.
Signed-off-by: Ben Shum <bshum@biblio.org> Signed-off-by: Bill Erickson <berickxx@gmail.com>
Ben Shum [Fri, 12 Sep 2014 21:58:11 +0000 (17:58 -0400)]
LP#1369169: Add websockets section to the OpenSRF README
Remove the separate README.websockets and move the contents into the primary
OpenSRF README document so that all steps are in one place.
Additional edits to the websockets instructions to detail differences made
between Ubuntu 14.04 Trusty and Debian / Ubuntu 12.04 Precise. More edits
may be necessary for Debian Jessie later?
Also, create a separate config file for Apache 2.4 that is copied into place
for Ubuntu Trusty and potentially other systems that will need it.
Signed-off-by: Ben Shum <bshum@biblio.org> Signed-off-by: Bill Erickson <berickxx@gmail.com>
Ben Shum [Sat, 13 Sep 2014 22:04:54 +0000 (18:04 -0400)]
LP#1369169: Add Apache 2.4 specific configuration file for websockets
For Apache 2.4, there were some necessary modifications for running the
websockets code properly. Similar to how we do things in Evergreen, we
added a new directory for apache_24 which contains the modified apache2.conf
file.
Signed-off-by: Ben Shum <bshum@biblio.org> Signed-off-by: Bill Erickson <berickxx@gmail.com>
Ben Shum [Sat, 13 Sep 2014 22:23:46 +0000 (18:23 -0400)]
LP#1369169: Mention the requirement for valid SSL certificate
The apache2-websockets instance will not start without a valid SSL certificate
in /etc/apache2/ssl. Include a mention of this in the README with the extra
stipulation that it is still possible to use a self-signed SSL certificate for
testing purposes, but this is not recommended for live installations.
Signed-off-by: Ben Shum <bshum@biblio.org> Signed-off-by: Bill Erickson <berickxx@gmail.com>
Ben Shum [Fri, 12 Sep 2014 21:58:11 +0000 (17:58 -0400)]
LP#1369169: Add websockets section to the OpenSRF README
Remove the separate README.websockets and move the contents into the primary
OpenSRF README document so that all steps are in one place.
Additional edits to the websockets instructions to detail differences made
between Ubuntu 14.04 Trusty and Debian / Ubuntu 12.04 Precise. More edits
may be necessary for Debian Jessie later?
Also, create a separate config file for Apache 2.4 that is copied into place
for Ubuntu Trusty and potentially other systems that will need it.
Signed-off-by: Ben Shum <bshum@biblio.org> Signed-off-by: Bill Erickson <berickxx@gmail.com>
Ben Shum [Sat, 13 Sep 2014 22:04:54 +0000 (18:04 -0400)]
LP#1369169: Add Apache 2.4 specific configuration file for websockets
For Apache 2.4, there were some necessary modifications for running the
websockets code properly. Similar to how we do things in Evergreen, we
added a new directory for apache_24 which contains the modified apache2.conf
file.
Signed-off-by: Ben Shum <bshum@biblio.org> Signed-off-by: Bill Erickson <berickxx@gmail.com>
This allows the OpenSRF JavaScript client library (or
to be precise, one that has been modified to direct
requests at a different domain) to take advantage of CORS
support.
Bennett Goble [Tue, 22 May 2012 15:57:56 +0000 (11:57 -0400)]
LP#1002028: Cross Origin Resource Sharing for OpenSRF
Background
----------
Browsers' same-origin policy currently restricts requests to the current
website's domain to prevent various nefarious scenarios. However,
because APIs and other web resources need to remain open to cross-site
use Cross Origin Resource Sharing (CORS) was created to allow services
to formally authorize cross-origin requests. CORS makes it simple to use
OpenSRF's HTTP translator and gateway APIs on websites using separate
domains.
Example Scenarios
-----------------
1) A library would like an AJAX-driven "quicksearch" box on their main
site, which is hosted on a different domain than their catalog.
2) A developer wants to create new web applications and services that
tie into Evergreen, but does not wish to install EG locally or
configure a proxy.
Implementation
--------------
The function crossOriginHeaders() has been added to apachetools.c.
Incoming requests are checked to see if they have an Origin header. The
value of the Origin header is checked against a whitelist defined in
opensrf_core.xml config (XPath: /config/gateway/cross_origin/origin).
The function returns 1 if CORS headers have been added to the response.
Notes
-----
* The OpenSRF Javascript client library (opensrf.js) defaults to the root
of the current web host "/osrf-http-translator." In addition, synchronous
requests are presumed in some situations: resulting in the oncomplete
method never returning (Blocking requests are not possible with cross-
domain XHR.)
* It is also possible to enable CORS with the Apache "set header"
configuration directive. However, this means that the necessary headers
would be appended to every response.
Links
-----
Specification - http://www.w3.org/TR/cors/
Wikipedia Article - http://en.wikipedia.org/wiki/Cross-origin_resource_sharing
Josh Stompro [Wed, 21 May 2014 13:26:53 +0000 (08:26 -0500)]
(doc) Reorder changes to ejabberd.cfg in install instructions
I found it annoying that the list of changes to make to ejabberd.cfg
didn't follow the order that the options showed up in the default
Debian ejabberd.cfg. I reordered them so after you finish changing one
option, you can search forward in the document for the next term.
Mike Rylander [Wed, 30 Jul 2014 17:29:46 +0000 (13:29 -0400)]
LP#1350457: Pass caller's session to subrequests called via method_lookup
In the process of looking up a method for an internal subrequest, we lose
session info. This is a problem when the subrequest makes a remote request,
because then the subrequest can't look up the proper locale, among other
things. The forthcoming branch passes the caller's session to the subrequest.
Signed-off-by: Mike Rylander <mrylander@gmail.com> Signed-off-by: Galen Charlton <gmc@esilibrary.com>
The most common form of XMPP error messages are "bounced" messages, i.e.
those where the recipient is not available. Instead of passing these
useless and confusing messages down to a drone for processing, log the
error in the listener and drop the message.
Signed-off-by: Bill Erickson <berick@esilibrary.com> Signed-off-by: Galen Charlton <gmc@esilibrary.com>
There appears to be a bug in Chromium where loading the same page
multiple times (without a refresh or cache clear) causes the
SharedWorker to fail to instantiate on every other page load.
Further research pending. Disabling SharedWorker's entirely for
now.
Note, to replicate, load a page using shared workers, focus the
browser address bar, hit Enter to load the page again. The shared
worker will fail to load on every other page load, though it will
appear to the SharedWorker caller (opensrf.js) that the port is open.
Signed-off-by: Bill Erickson <berick@esilibrary.com> Signed-off-by: Galen Charlton <gmc@esilibrary.com>
* avoid unneccessary and wrong incantation of apr_thread_exit. The two
sub-threads now both live for the duration of the process.
* to be safe, create thread mutex before threads
Signed-off-by: Bill Erickson <berick@esilibrary.com> Signed-off-by: Galen Charlton <gmc@esilibrary.com>
It was falling behind the shared lib in bug fixes and features. A
per-tab WS implementation is (maybe) a dangerous thing to have around,
as well, since it encourages /many/ connections. Can resurrect later if
needed.
Signed-off-by: Bill Erickson <berick@esilibrary.com> Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Bill Erickson [Mon, 3 Mar 2014 15:29:23 +0000 (10:29 -0500)]
LP#1268619: websocket: avoid module auto configuration
We don't want osrf_websocket_translator to be directly loaded as a
module, since it is not an apache module, but a shared library loaded by
an apache module (mod_websockets). This is especially true of the default
apache instance.
Signed-off-by: Bill Erickson <berick@esilibrary.com> Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Added support for an idle timeout and idle check interval configuration
variables. These allow each websocket apache process to kick off
clients that have been connected and are idle for too long, thus hogging
a process unnecessarily.
Added a SIGUSR1 signal handler which forces the idle timeout to be very
low and a short re-check period so that the client can be kicked as soon
as there are no open conversations.
Signed-off-by: Bill Erickson <berick@esilibrary.com> Signed-off-by: Galen Charlton <gmc@esilibrary.com>
* starting packet inspection
* activity log; recipient removal
* only cache connected recipients; use request_rec pool for session_pool parent
* wrap all thread work in mutex
* session memory goodness
Signed-off-by: Bill Erickson <berick@esilibrary.com> Signed-off-by: Galen Charlton <gmc@esilibrary.com>
* use jsonObjectFree() on jsonObjets, not free();
* removed some debugging logs
* accommodate API changes for Apache 2.4
* safer logging:
Avoid using ap_log_rerror, in particular referencing server->request
from the responder thread, since the request_rec will be invalid after
on_disconnect is called.
Signed-off-by: Bill Erickson <berick@esilibrary.com> Signed-off-by: Galen Charlton <gmc@esilibrary.com>
OpenSRF can run mutiple times, as different users, on one host.
Right now we look for all service processes, but we should only
look for our own. This patch does that.
Signed-off-by: Mike Rylander <mrylander@gmail.com> Signed-off-by: Galen Charlton <gmc@esilibrary.com>