php-general Digest 22 Jun 2008 17:24:58 -0000 Issue 5528
Topics (messages 275781 through 275785):
Re: Installing PEAR on machines without internet access.
275781 by: Lester Caine
Re: Military Service WAS [PHP] Capitalization of variable
275782 by: Sancar Saran
Re: Another canvas example
275783 by: Richard Heyes
Communicated-Key/Token for SOAP Authentication
275784 by: Steve Finkelstein
275785 by: Kyle Browning
Administrivia:
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
[EMAIL PROTECTED]
----------------------------------------------------------------------
--- Begin Message ---
Gregory Beaver wrote:
Lester Caine wrote:
I've been going through the hoops documenting installation and recovery
notes for my customer sites. The majority of these run local web
services with no internet access from the servers, so with the
increasing reliance on PEAR extensions, I'm looking to the correct way
to 'install' PEAR packages.
Currently I just clone the PEAR directory from another machine. Is this
the only way ?
This will work if and *only* if the paths are the same on the
destination machine. If so, this works fine. Otherwise, you can
install PEAR directly just as PHP does, using install-pear-nozlib.phar,
check out the pear/ directory in your unix-based PHP distribution for
the Makefile.frag that shows usage. After PEAR is installed, you can
install packages directly from tarball via the command-line.
pear install Package-1.2.3.tgz
Main problem I'm finding is working on site and hitting something that is not
in the PHP download already. Although these sites are slowly allowing internet
access, you can guarantee you forget to pick something on one that isn't :(
Shitting windows has the same problem of cause - requires a working internet
connection for some key steps and at 10pm trying to get a customers system
back on line ....
I have a large USB disk with almost everything I need - it would be nice to be
able to simply download PEAR since many projects have stopped bothering to
include the bits they use :(
Greg
P.S. PEAR questions are best asked on [EMAIL PROTECTED], the
best support for PEAR is on that list.
Another pile of stuff just for one question :(
--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
--- End Message ---
--- Begin Message ---
On Saturday 21 June 2008 16:58:24 Michelle Konzack wrote:
> Merhaba Sancar,
>
> Am 2008-06-20 09:21:30, schrieb Sancar Saran:
> > The Turkish Gendarmerie (Jandarma Genel Komutanligi)
>
> ;-)
>
> How long is the service there?
15 Months.
> Thanks, Greetings and nice Day/Evening
> Michelle Konzack
> Systemadministrator
> 24V Electronic Engineer
> Tamay Dogan Network
> Debian GNU/Linux Consultant
--- End Message ---
--- Begin Message ---
Hi,
You gonna post the source code? ;)
Already have, like all Javascript, it's clientside. The direct URL is:
http://www.phpguru.org/pie/pie.js
There's also the ExCanvas library, but that's public anyway.
--
Richard Heyes
Employ me:
http://www.phpguru.org/cv
+----------------------------------------+
| Access SSH with a Windows mapped drive |
| http://www.phpguru.org/sftpdrive |
+----------------------------------------+
--- End Message ---
--- Begin Message ---
Hi all,
I'm working on a relatively straight forward Web API that'll have a
SOAP presence. The most secure way of going about doing
authentication would be undoubtedly client-certificate authentication.
I have been able to implement such a service straight forward as
there is plenty of documentation out there covering how to do so. I
have some clients who're reluctant to manage client certificates at
this point in time, and do prefer a communicated-key authentication,
very similar to what Amazon and a few of the other big boys do. I'm
having a bit of a difficult time coming up with multiple solutions as
to how to properly implement this for my service besides stuffing a
random hash into my database and making them send it to me over SSL
through their message payload. I can then compare the hash against
what's in the database + their IP, or something else.
Would anyone be able to suggest some algorithm for the way I'm
handling the tokens that's more secure and less "brute-forcible" than
the methodology I described above? My objective in this exercise is
not to only authenticate who's sending me the SOAP envelope, but also
to ensure that whatever token/key system I implement is not open for
very simple brute force. If they're able to knock down my brick
house, I have other problems --- but I definitely want to build that
brick foundation.
Suggestions, web articles, books etc., are all welcome!
Thank you for any advice from you avid web service gurus.
/sf
--- End Message ---
--- Begin Message ---
Checkout oAuth, to either see how they used it, or for the algo's
http://oauth.net
Kyle
On Sun, Jun 22, 2008 at 7:53 AM, Steve Finkelstein <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I'm working on a relatively straight forward Web API that'll have a
> SOAP presence. The most secure way of going about doing
> authentication would be undoubtedly client-certificate authentication.
> I have been able to implement such a service straight forward as
> there is plenty of documentation out there covering how to do so. I
> have some clients who're reluctant to manage client certificates at
> this point in time, and do prefer a communicated-key authentication,
> very similar to what Amazon and a few of the other big boys do. I'm
> having a bit of a difficult time coming up with multiple solutions as
> to how to properly implement this for my service besides stuffing a
> random hash into my database and making them send it to me over SSL
> through their message payload. I can then compare the hash against
> what's in the database + their IP, or something else.
>
> Would anyone be able to suggest some algorithm for the way I'm
> handling the tokens that's more secure and less "brute-forcible" than
> the methodology I described above? My objective in this exercise is
> not to only authenticate who's sending me the SOAP envelope, but also
> to ensure that whatever token/key system I implement is not open for
> very simple brute force. If they're able to knock down my brick
> house, I have other problems --- but I definitely want to build that
> brick foundation.
>
> Suggestions, web articles, books etc., are all welcome!
>
> Thank you for any advice from you avid web service gurus.
>
> /sf
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--- End Message ---
