php-general Digest 18 Aug 2009 06:16:07 -0000 Issue 6291
Topics (messages 296892 through 296908):
Re: is there a better way to know from which php file the request comes from ??
296892 by: Ashley Sheridan
296894 by: Ben Dunlap
296897 by: Tom Worster
296898 by: Tom Worster
296899 by: Shawn McKenzie
296900 by: Shawn McKenzie
296902 by: Eddie Drapkin
296903 by: Shawn McKenzie
296904 by: Ralph Deffke
Re: Sanitizing mysql inserts of user data
296893 by: Dotan Cohen
296895 by: Paul M Foster
296896 by: Ben Dunlap
SMDR/CDR daemon/processor
296901 by: Jim Lucas
296906 by: Per Jessen
296908 by: Jim Lucas
daemon without pcntl_fork
296905 by: Jim Lucas
296907 by: Lars Torben Wilson
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
On Mon, 2009-08-17 at 19:04 +0200, Ralph Deffke wrote:
> If u need a solution to know where the request comes from on a certain
> secure level u can use cookies.
>
> u might also have run into pages on the web giving u hard readable images u
> have to put into a form field. toghether with cookies these design gives u
> 1000% from where the form data come.
>
> depends what security level u whant to implement
>
> regards
> ralph_def...@yahoo.de
>
>
> "nashrul" <anas_a...@yahoo.com> wrote in message
> news:25003587.p...@talk.nabble.com...
> >
> > This is a newbie question...
> > Let's say there are 3 php files, page1.php, page2.php and page3.php. Form
> > submission from page1.php or page2.php will take user to page3.php.
> > I know that we can use parameter that is appended in the action attribute
> of
> > the form (e.g <FORM METHOD=POST ACTION="tes.php?var1=val1">)
> > But I think, appending this parameter is transparent to the user, since
> it's
> > visible in the url.
> > And I think we can also use the hidden field or (form name ??.).
> > So which one is most secured and better ??
> > Thanks..
> > --
> > View this message in context:
> http://www.nabble.com/is-there-a-better-way-to-know-from-which-php-file-the-request-comes-from----tp25003587p25003587.html
> > Sent from the PHP - General mailing list archive at Nabble.com.
> >
>
>
>
Nothing that comes from the client can be considered secure, so cookies
are out too I'm afraid.
Thanks,
Ash
http://www.ashleysheridan.co.uk
--- End Message ---
--- Begin Message ---
> This is a newbie question...
> Let's say there are 3 php files, page1.php, page2.php and page3.php. Form
> submission from page1.php or page2.php will take user to page3.php.
> I know that we can use parameter that is appended in the action attribute of
> the form (e.g <FORM METHOD=POST ACTION="tes.php?var1=val1">)
> But I think, appending this parameter is transparent to the user, since it's
> visible in the url.
Why does it matter?
I don't meant to suggest that it doesn't, but I'm just wondering if
you could explain the design of your app a bit.
You've sketched out an attack scenario in which a user maliciously
alters a variable in the request so that page3.php thinks the request
is coming from page2.php, when in fact it's coming from page1.php --
or vice versa.
But suppose an attacker does trick page3.php into mistaking the origin
of the POST. Does it make a difference? Presumably page3.php will be
filtering all of its input, and will discard the request if, for
example, it claims to be from page2.php but doesn't contain the sort
of data that a request from page2 would contain.
But if it does contain the right data, and the data is valid, then
does it matter if the data was not actually collected on page2.php?
The statelessness of HTTP can be one of its beauties -- and I would be
inclined against introducing statefulness unless the app really needs
it.
At any rate your problem is reminiscent of CSRF:
http://en.wikipedia.org/wiki/Cross-site_request_forgery
And I'm wondering if you could borrow from anti-CSRF techniques to
solve it (assuming, again, that it really needs to be solved).
Ben
--- End Message ---
--- Begin Message ---
On 8/17/09 5:24 AM, "Ashley Sheridan" <a...@ashleysheridan.co.uk> wrote:
> On Mon, 2009-08-17 at 02:17 -0700, nashrul wrote:
>> This is a newbie question...
>> Let's say there are 3 php files, page1.php, page2.php and page3.php. Form
>> submission from page1.php or page2.php will take user to page3.php.
>> I know that we can use parameter that is appended in the action attribute of
>> the form (e.g <FORM METHOD=POST ACTION="tes.php?var1=val1">)
>> But I think, appending this parameter is transparent to the user, since it's
>> visible in the url.
>> And I think we can also use the hidden field or (form name ??.).
>> So which one is most secured and better ??
>> Thanks..
>> --
>> View this message in context:
>> http://www.nabble.com/is-there-a-better-way-to-know-from-which-php-file-the-r
>> equest-comes-from----tp25003587p25003587.html
>> Sent from the PHP - General mailing list archive at Nabble.com.
>>
>>
> Neither GET or POST is more secure, it's just that POST requires a tiny
> bit more work to see what's being sent. You can use the
> $_SERVER['HTTP_REFERER'] variable to detect where a request has come
> from. The documentation for this particular variable mentions that it
> can't be trusted, as it can be changed by the client browser, but then,
> so can hidden form fields, etc. Personally, I'd go with the HTTP_REFERER
> route, because it is completely transparent, and the majority of users
> aren't going to bother changing it.
your probably right. though i remember when i considered using HTTP_REFERER.
i looked up the http rfc and it said that use of the header was optional.
that made sense. so i decided not to make any of app functionality depend on
it.
--- End Message ---
--- Begin Message ---
On 8/17/09 5:17 AM, "nashrul" <anas_a...@yahoo.com> wrote:
> This is a newbie question...
> Let's say there are 3 php files, page1.php, page2.php and page3.php. Form
> submission from page1.php or page2.php will take user to page3.php.
> I know that we can use parameter that is appended in the action attribute of
> the form (e.g <FORM METHOD=POST ACTION="tes.php?var1=val1">)
> But I think, appending this parameter is transparent to the user, since it's
> visible in the url.
> And I think we can also use the hidden field or (form name ??.).
> So which one is most secured and better ??
i'm not in love with using the form POST method combined with an action url
that includes pseudo-GET parameters.
for POST forms, i use a convention of always having a hidden input in the
form to indicate which form sent the query, e.g.
<input type="hidden" name="whichform" value="foobarform">
this also comes in handy if one server script processes more than one form.
as for security, there's little difference between this method, using GET
values, using HTTP_REFERER, or what have you. protection against spoofing
lies not in these choices.
--- End Message ---
--- Begin Message ---
nashrul wrote:
> This is a newbie question...
> Let's say there are 3 php files, page1.php, page2.php and page3.php. Form
> submission from page1.php or page2.php will take user to page3.php.
> I know that we can use parameter that is appended in the action attribute of
> the form (e.g <FORM METHOD=POST ACTION="tes.php?var1=val1">)
> But I think, appending this parameter is transparent to the user, since it's
> visible in the url.
> And I think we can also use the hidden field or (form name ??.).
> So which one is most secured and better ??
> Thanks..
I personally don't see a problem with using get or post vars, but to
keep the user from being able to manipulate it do this. This could also
be in a header file included at the top of all pages:
//page1.php and page2.php
session_start();
$_SESSION['page'] = $_SERVER['PHP_SELF'];
//page3.php
session_start();
$page = $_SESSION['page']
// use $page somehow . . .
--
Thanks!
-Shawn
http://www.spidean.com
--- End Message ---
--- Begin Message ---
nashrul wrote:
> This is a newbie question...
> Let's say there are 3 php files, page1.php, page2.php and page3.php. Form
> submission from page1.php or page2.php will take user to page3.php.
> I know that we can use parameter that is appended in the action attribute of
> the form (e.g <FORM METHOD=POST ACTION="tes.php?var1=val1">)
> But I think, appending this parameter is transparent to the user, since it's
> visible in the url.
> And I think we can also use the hidden field or (form name ??.).
> So which one is most secured and better ??
> Thanks..
I personally don't see a problem with using get or post vars, but to
keep the user from being able to manipulate it do this. This could also
be in a header file included at the top of all pages:
//page1.php and page2.php
session_start();
$_SESSION['page'] = $_SERVER['PHP_SELF'];
//page3.php
session_start();
$page = $_SESSION['page']
// use $page somehow . . .
--
Thanks!
-Shawn
http://www.spidean.com
--- End Message ---
--- Begin Message ---
On Mon, Aug 17, 2009 at 5:31 PM, Shawn McKenzie<nos...@mckenzies.net> wrote:
> nashrul wrote:
>> This is a newbie question...
>> Let's say there are 3 php files, page1.php, page2.php and page3.php. Form
>> submission from page1.php or page2.php will take user to page3.php.
>> I know that we can use parameter that is appended in the action attribute of
>> the form (e.g <FORM METHOD=POST ACTION="tes.php?var1=val1">)
>> But I think, appending this parameter is transparent to the user, since it's
>> visible in the url.
>> And I think we can also use the hidden field or (form name ??.).
>> So which one is most secured and better ??
>> Thanks..
>
> I personally don't see a problem with using get or post vars, but to
> keep the user from being able to manipulate it do this. This could also
> be in a header file included at the top of all pages:
>
> //page1.php and page2.php
> session_start();
> $_SESSION['page'] = $_SERVER['PHP_SELF'];
>
> //page3.php
> session_start();
> $page = $_SESSION['page']
> // use $page somehow . . .
>
> --
> Thanks!
> -Shawn
> http://www.spidean.com
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
This approach degrades very simply:
1) Say you have four pages, a.php, b.php, c.php and d.php.
2) b expects user to come from a, d from c.
3) I open two tabs, a.php and c.php.
4) $_SESSION['from'] is now c.php
5) I post to b from a, get an error. $_SESSION['from'] is now b.php.
6) I post to d from c and get an error.
Obviously this example is a tad bit contrived, but as long as your
user is browsing your site in more than one tab/window, using that
approach will break often and result in a user experience, so I'd
stick away from it.
As far as relying on cookies, HTTP headers, hidden form fields, etc.
they are all user input, and Lesson 1 in Security 101 that you don't
trust user input. Ever. I always assume that the best HTTP blackhats
are after my sites when I write them and make them unnecessarily
overthought, but they're secure. I even let a few
(black|white|grey)hat friends of mine take a peak at the code, when I
can, to get their input. If you can think of a way to exploit your
code, so can someone else. And so will someone else.
Generally speaking, I'm not entirely sure that this is a question that
even needs an answer. I'm going to have to echo a sentiment from
earlier in the thread that you need to be validating all of your data
anyway, so it shouldn't matter if I POST to page3 from page2 or from
page1 or from a CLI app written with curl/wget. What should matter is
whether or not the data I'm POST'ing meets the security criteria that
you've dictated (whatever that may be) and gets properly
escaped/filtered before being entered into the database or otherwise
used. I'd venture so far as to say that if you need to care about
where a form is POST'd from for security, you have a flawed security
model and in all likelihood a very insecure application and some
serious refactoring to do.
I can't imagine a situation where dictating page2 comes from page1 and
page3 comes from page2 is necessary for security at all. Perhaps I'm
being shortsited and you can provide some examples?
--- End Message ---
--- Begin Message ---
Eddie Drapkin wrote:
> On Mon, Aug 17, 2009 at 5:31 PM, Shawn McKenzie<nos...@mckenzies.net> wrote:
>> nashrul wrote:
>>> This is a newbie question...
>>> Let's say there are 3 php files, page1.php, page2.php and page3.php. Form
>>> submission from page1.php or page2.php will take user to page3.php.
>>> I know that we can use parameter that is appended in the action attribute of
>>> the form (e.g <FORM METHOD=POST ACTION="tes.php?var1=val1">)
>>> But I think, appending this parameter is transparent to the user, since it's
>>> visible in the url.
>>> And I think we can also use the hidden field or (form name ??.).
>>> So which one is most secured and better ??
>>> Thanks..
>> I personally don't see a problem with using get or post vars, but to
>> keep the user from being able to manipulate it do this. This could also
>> be in a header file included at the top of all pages:
>>
>> //page1.php and page2.php
>> session_start();
>> $_SESSION['page'] = $_SERVER['PHP_SELF'];
>>
>> //page3.php
>> session_start();
>> $page = $_SESSION['page']
>> // use $page somehow . . .
>>
>> --
>> Thanks!
>> -Shawn
>> http://www.spidean.com
>>
>> --
>> PHP General Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>
> This approach degrades very simply:
>
> 1) Say you have four pages, a.php, b.php, c.php and d.php.
> 2) b expects user to come from a, d from c.
> 3) I open two tabs, a.php and c.php.
> 4) $_SESSION['from'] is now c.php
> 5) I post to b from a, get an error. $_SESSION['from'] is now b.php.
> 6) I post to d from c and get an error.
>
Yep, I didn't really think it through :-(
--
Thanks!
-Shawn
http://www.spidean.com
--- End Message ---
--- Begin Message ---
I was reviewing ur post, and thinking u might talk about a pretty common
application like in a sequence of order form u want first the billing data
then the shipping data. for both u need just the same form u then process on
script3.
in such a case it doesn't matter if u use hidden fields or url parameter,
GET or POST to run different code for each form data in sript 3 neither can
I see a security issue here. u processing only the variables u defined. and
what does it matter if you have an hidden field like stepp=1 or stepp=2 and
a bored user put just for fun stepp=99 to piek ur ass. just take care in ur
code for it and display something (e.g. "hang on , big brother is watching
u")
this is good practice and common all over. any PHPer got his own way to do
it, and I think u r in the process to find urs. just try what u like best.
if you have a real security issue come back with more details about the
SECURITY issue and I m shure the group will have a good brainstorm going
again.
have fun
ralph_def...@yahoo.de
"nashrul" <anas_a...@yahoo.com> wrote in message
news:25003587.p...@talk.nabble.com...
>
> This is a newbie question...
> Let's say there are 3 php files, page1.php, page2.php and page3.php. Form
> submission from page1.php or page2.php will take user to page3.php.
> I know that we can use parameter that is appended in the action attribute
of
> the form (e.g <FORM METHOD=POST ACTION="tes.php?var1=val1">)
> But I think, appending this parameter is transparent to the user, since
it's
> visible in the url.
> And I think we can also use the hidden field or (form name ??.).
> So which one is most secured and better ??
> Thanks..
> --
> View this message in context:
http://www.nabble.com/is-there-a-better-way-to-know-from-which-php-file-the-request-comes-from----tp25003587p25003587.html
> Sent from the PHP - General mailing list archive at Nabble.com.
>
--- End Message ---
--- Begin Message ---
>> Logically, it does _not_ mean the same thing.
>
> Definitely not -- it would be a bit presumptuous to claim "If you do
> X, the query is not vulnerable to SQL injection attacks" for just
> about any value of X.
>
That is what I though: no magic bullet.
> That said, I would recommend binding parameters if you can. It's a
> cleaner way of separating the logic of a query from its data, and
> theoretically more reliable than mysql_real_escape_string():
>
> http://en.wikipedia.org/wiki/SQL_injection#Parameterized_statements
>
I fail to understand what is happening here. For the sake of context,
here is the PHP code in TFA:
$db = new PDO('pgsql:dbname=database');
$stmt = $db->prepare("SELECT priv FROM testUsers WHERE
username=:username AND password=:password");
$stmt->bindParam(':username', $user);
$stmt->bindParam(':password', $pass);
$stmt->execute();
What exactly does bindParam do? I read these pages in TFM but I still
do not understand what exactly is being sent to the database:
http://il2.php.net/manual/en/function.db2-bind-param.php
http://il2.php.net/manual/en/function.maxdb-stmt-bind-param.php
http://il2.php.net/manual/en/mysqli-stmt.bind-param.php
I do not see how there could possibly be a prepared statement for a
user comment. I am not a programmer by trade, so I may be missing
something obvious. If so, a link and a friendly RTFM would be great.
--
Dotan Cohen
http://what-is-what.com
http://gibberish.co.il
--- End Message ---
--- Begin Message ---
On Mon, Aug 17, 2009 at 10:10:47PM +0300, Dotan Cohen wrote:
> >> Logically, it does _not_ mean the same thing.
> >
> > Definitely not -- it would be a bit presumptuous to claim "If you do
> > X, the query is not vulnerable to SQL injection attacks" for just
> > about any value of X.
> >
>
> That is what I though: no magic bullet.
>
>
> > That said, I would recommend binding parameters if you can. It's a
> > cleaner way of separating the logic of a query from its data, and
> > theoretically more reliable than mysql_real_escape_string():
> >
> > http://en.wikipedia.org/wiki/SQL_injection#Parameterized_statements
> >
>
> I fail to understand what is happening here. For the sake of context,
> here is the PHP code in TFA:
> $db = new PDO('pgsql:dbname=database');
> $stmt = $db->prepare("SELECT priv FROM testUsers WHERE
> username=:username AND password=:password");
> $stmt->bindParam(':username', $user);
> $stmt->bindParam(':password', $pass);
> $stmt->execute();
>
> What exactly does bindParam do? I read these pages in TFM but I still
> do not understand what exactly is being sent to the database:
> http://il2.php.net/manual/en/function.db2-bind-param.php
> http://il2.php.net/manual/en/function.maxdb-stmt-bind-param.php
> http://il2.php.net/manual/en/mysqli-stmt.bind-param.php
>
> I do not see how there could possibly be a prepared statement for a
> user comment. I am not a programmer by trade, so I may be missing
> something obvious. If so, a link and a friendly RTFM would be great.
Typically, prepared statements do a couple of things. First, they ensure
that values sent to the DBMS are properly "quoted". You'd be surprised
how difficult a problem that is. Date and string values must be
surrounded by quotes, but numerics shouldn't be. And how they're quoted
depends on the DBMS you're using. So prepared statements take care of
this for you.
The second thing they do is examine the values you're attempting to pass
into the database, and ensure they don't contain SQL injection type
code. This is hard to explain, but it's relatively simple to insert
"code" in place of an actual value, and do malicious things to your
database, or obtain information you don't want users to see (like credit
card numbers). If you're curious, search for "SQL injection" to get more
information and see examples.
When you put something like "username = :username" in the arguments for
the prepare() function, the second parameter (:username) is really just
a placeholder for a value. It tells MySQL that this is where you want a
username to go in the final statement. The bindParam() function tells
MySQL the actual value you want to substitute for that placeholder. In
your case, it's a PHP variable named $user. When you call the execute()
function, it puts the values together with their placeholders, forms a
complete statement, and sends that off to the MySQL database engine.
I haven't followed this thread, so I don't know what you mean by, "I
do not see how there could possibly be a prepared statement for a user
comment." Maybe someone else can answer that part of your query.
Paul
--
Paul M. Foster
--- End Message ---
--- Begin Message ---
>> $stmt = $db->prepare("SELECT priv FROM testUsers WHERE
>> username=:username AND password=:password");
>> $stmt->bindParam(':username', $user);
>> $stmt->bindParam(':password', $pass);
>> $stmt->execute();
[8<]
> I haven't followed this thread, so I don't know what you mean by, "I
> do not see how there could possibly be a prepared statement for a user
> comment." Maybe someone else can answer that part of your query.
Thanks Paul, that was a much better explanation than the one I was
attempting. I'm guessing the OP was being thrown off by the colons in
the SELECT statement above. I can see how those could look like
comments to someone not familiar with PDO and named parameters.
Ben
--- End Message ---
--- Begin Message ---
I was asked the other day to build a Station Message Detail Recording
(SMDR) or Call Detail Record (CDR) processor for a client. I started
searching for examples of such a thing. I mostly found commercial apps
to handle the job.
I could not find anything on Hotscripts, phpGround.com, and a few others.
I did find a few Open Source things on Source Forge.
http://sourceforge.net/projects/simplesmdr/
It is active, but has missing files...
References /home/administrator/*
Those were not included though...
http://sourceforge.net/projects/opensmdr/
Written in PHP, but it hasn't been touched since 2004.
http://sourceforge.net/projects/astbilling/
Haven't had a chance to look at it yet.
My question: has anybody worked with any type of project that involved
capturing/parsing/storing/regurgitating such information?
also, have you ever worked with this or similar devices?
http://www.precidia.com/products/ipocket_232.html
TIA!
Jim Lucas
--- End Message ---
--- Begin Message ---
Jim Lucas wrote:
> I was asked the other day to build a Station Message Detail Recording
> (SMDR) or Call Detail Record (CDR) processor for a client. I started
> searching for examples of such a thing. I mostly found commercial apps
> to handle the job.
What sort of processing do you need? I just record all CDRs in a
database, mostly as an easily accessible audit trail.
> My question: has anybody worked with any type of project that involved
> capturing/parsing/storing/regurgitating such information?
Asterisk does the capturing/parsing/storing bit for you, but you didn't
mention Asterisk, so that may not be of much use.
/Per
--
Per Jessen, Zürich (19.3°C)
--- End Message ---
--- Begin Message ---
Per Jessen wrote:
Jim Lucas wrote:
I was asked the other day to build a Station Message Detail Recording
(SMDR) or Call Detail Record (CDR) processor for a client. I started
searching for examples of such a thing. I mostly found commercial apps
to handle the job.
What sort of processing do you need? I just record all CDRs in a
database, mostly as an easily accessible audit trail.
The idea is to create a SMDR/CDR processor that will work with most main stream PBX systems. Not
just Asterisk. NEC, Avaya, Panasonic, etc...
Example is, even NEC has a hand full of formats that is outputs the data in. Include/exclude the
date column. That sort of thing.
My question: has anybody worked with any type of project that involved
capturing/parsing/storing/regurgitating such information?
Asterisk does the capturing/parsing/storing bit for you, but you didn't
mention Asterisk, so that may not be of much use.
It is a part of the project in whole, it merely is but one of many different
formats.
Thanks for the information!
/Per
--
Jim Lucas
"Some men are born to greatness, some achieve greatness,
and some have greatness thrust upon them."
Twelfth Night, Act II, Scene V
by William Shakespeare
--- End Message ---
--- Begin Message ---
Does anybody know how to use PHP as a daemon without the use of pcntl_fork.
http://php.net/pcntl_fork
I don't want to have to have a person have a special/custom compilation
of PHP just to run a simple daemon.
My system: OpenBSD 4.5 w/PHP v5.2.8
I want to launch a daemon out of the /etc/rc.local when the system starts.
My goal is to write a script that will be launched from /etc/rc.local
when a system boots. I want it to be detached from any shell or ssh
login that I launch it from also.
Anybody have any idea on how to do this?
I have played with system() and it does work.
test.php:
<?php
echo 'Starting';
system('/usr/local/bin/php test_cli.php >/dev/null &');
echo 'Done';
?>
test_cli.php
<?php
for( $i=1; $i<=10; $i++ ) {
echo "Echo {$i}\n";
sleep(1);
}
echo 'Done';
?>
The above, when called, launches test_cli.php and detaches it from the
cli and returns to the system prompt
Well, after writing all this out, I think I have answered by own question.
If anybody else has a better suggestion, I am all ears.
If you have a better way of doing it, please share.
Also, a second piece to this would be a script to manage
(start/stop/restart/etc...) the parent daemon.
Something along the line of apachectl or similar.
TIA!
Update to the last email also.
I found another device that does RS232 to ethernet:
http://www.hw-group.com/products/portstore2/index_en.html
Anybody work with one of these?
Again, thanks!
Jim Lucas
--- End Message ---
--- Begin Message ---
2009/8/17 Jim Lucas <li...@cmsws.com>:
> Does anybody know how to use PHP as a daemon without the use of pcntl_fork.
>
> http://php.net/pcntl_fork
Hi Jim,
AFAIK you can't. Read on. . .
> I don't want to have to have a person have a special/custom compilation
> of PHP just to run a simple daemon.
>
> My system: OpenBSD 4.5 w/PHP v5.2.8
>
> I want to launch a daemon out of the /etc/rc.local when the system starts.
>
> My goal is to write a script that will be launched from /etc/rc.local
> when a system boots. I want it to be detached from any shell or ssh
> login that I launch it from also.
>
> Anybody have any idea on how to do this?
>
> I have played with system() and it does work.
What you've done below is not create a daemon, but a background
process. It's still attached to the shell you started it in (try
killing the shell you started it from and see what happens). There are
other differences too. IMHO the approach you've used here does have
its uses, and I've used it (and still do) when it's appropriate, but
when what you need is a daemon, then faking it with a background
process just isn't enough.
Compiling in pcntl isn't really that big of a deal--depending on
exactly what you're trying to accomplish. Why is it a problem in your
case? Perhaps there is another way around the issue which has a
cleaner solution. For the cases I've run into, pcntl has worked
admirably.
> test.php:
> <?php
> echo 'Starting';
> system('/usr/local/bin/php test_cli.php >/dev/null &');
> echo 'Done';
> ?>
>
> test_cli.php
> <?php
>
> for( $i=1; $i<=10; $i++ ) {
> echo "Echo {$i}\n";
> sleep(1);
> }
>
> echo 'Done';
>
> ?>
>
> The above, when called, launches test_cli.php and detaches it from the
> cli and returns to the system prompt
>
>
> Well, after writing all this out, I think I have answered by own question.
>
> If anybody else has a better suggestion, I am all ears.
>
> If you have a better way of doing it, please share.
>
> Also, a second piece to this would be a script to manage
> (start/stop/restart/etc...) the parent daemon.
>
> Something along the line of apachectl or similar.
>
> TIA!
>
> Update to the last email also.
>
> I found another device that does RS232 to ethernet:
>
> http://www.hw-group.com/products/portstore2/index_en.html
>
> Anybody work with one of these?
Not me. But I've solved similar problems using ser2net (see
http://sourceforge.net/projects/ser2net/ ), sometimes running it on a
small embedded Linux device. Works great and I don't have to pay
someone else to sell me a free solution. :) But again, it depends on
your actual situation and what problem you're trying to solve. On the
face of it the device you linked looks OK. (I'm afraid I missed your
earlier post on the topic.)
> Again, thanks!
>
> Jim Lucas
I'm not trying to shoot down any ideas you've had or anything, just
wondering what's so bad about compiling pcntl in and hoping that maybe
you can save a few bucks on the serial-to-network problem by making
use of existing free software. Post more about what your situation is
and who knows? Maybe a fakey-daemon using background processes and a
proprietary serial-to-network device really is the best answer for
you.
Either way, good luck!
Regards,
Torben
--- End Message ---
