Services, API keys, tests, etc.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

All,

So I've got two Services packages that are pretty much ready
to go.  
Services_Facebook is a ground up fully functional interface
to all of  
the Facebook endpoints (it even supports photo uploads,
which *ahem*  
Facebook's own doesn't). Services_Flickr is a package I
coded over a  
year ago and my lazy ass just never finished.

Now, both of these services have both public'ish API keys
and  
secrets. The problem I have is publicly exposing my API keys
and  
secrets via my package's tests. With Facebook it's minimized
because  
you have to add the Services_Facebook PEAR application to
your  
profile (I've created a junk account specifically for the
tests), but  
Flickr is a bit more open I think, though you'd need to give
the  
package access to your Flickr account before write
operations could  
happen.

I suppose I could create a junk Flickr account and do the
same thing  
I did with Facebook ...

Thoughts?

- --Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFG8HO/h0MUGpYY9OQRAhoOAKDIOnZcfFul3BQXWfgM0kYhw2wEsACe
Mju2
2Oc8pviy71viKh/vOoqmoyg=
=ibm0
-----END PGP SIGNATURE-----

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

On Sep 18, 2007, at 5:56 PM, Joe Stump wrote:

> Now, both of these services have both public'ish API
keys and  
> secrets. The problem I have is publicly exposing my API
keys and  
> secrets via my package's tests. With Facebook it's
minimized  
> because you have to add the Services_Facebook PEAR
application to  
> your profile (I've created a junk account specifically
for the  
> tests), but Flickr is a bit more open I think, though
you'd need to  
> give the package access to your Flickr account before
write  
> operations could happen.
>
> I suppose I could create a junk Flickr account and do
the same  
> thing I did with Facebook ...
>
> Thoughts?

My plan for this sort of thing -- I'm running into a similar
issue  
with unit tests for the new VersionControl_SVN package -- is
to have  
a tests directory that contains a README, with instructions
on how  
the tests directory needs to have "sensitive.ini"
or some other sort  
of config file in it.

That README defines what the config file needs to have, such
as keys,  
shared secrets, etc. in order for tests to run properly.

Then you commit and release the package with everything
*but* your  
sensitive config information. Those who really want to run
tests can  
read the README and configure their own local environment
accordingly  
to run the tests.

Might be worth an RFC for a "test/secrets.ini"
proposal, so that  
there's one place that all packages which have tests that
need some  
sort of account information can look for that info.

secrets.ini:

[VersionControl_SVN]
login: clay
password: foo

[Services_Flickr]
api_key: 1234456778889

[Services_Facebook]
apikey: 12356789

... and so on. The test can load parse_ini_file('tests/ 
secrets.ini', true) and pick out the credentials needed by
the package.

Given the rise of web service packages that need exactly
this sort of  
thing, this sounds better to me with every keystroke. 

-Clay

--
Killersoft.com

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Looking forward to Services_Flickr.
Are you planning to implement all the API features?

-janisto

Joe Stump wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> All,
> 
> So I've got two Services packages that are pretty much
ready to go. 
> Services_Facebook is a ground up fully functional
interface to all of 
> the Facebook endpoints (it even supports photo uploads,
which *ahem* 
> Facebook's own doesn't). Services_Flickr is a package I
coded over a 
> year ago and my lazy ass just never finished.
> 
> Now, both of these services have both public'ish API
keys and secrets. 
> The problem I have is publicly exposing my API keys and
secrets via my 
> package's tests. With Facebook it's minimized because
you have to add 
> the Services_Facebook PEAR application to your profile
(I've created a 
> junk account specifically for the tests), but Flickr is
a bit more open 
> I think, though you'd need to give the package access
to your Flickr 
> account before write operations could happen.
> 
> I suppose I could create a junk Flickr account and do
the same thing I 
> did with Facebook ...
> 
> Thoughts?
> 
> - --Joe
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Darwin)
> 
>
iD8DBQFG8HO/h0MUGpYY9OQRAhoOAKDIOnZcfFul3BQXWfgM0kYhw2wEsACe
Mju2
> 2Oc8pviy71viKh/vOoqmoyg=
> =ibm0
> -----END PGP SIGNATURE-----
> 

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

On 9/18/07, Clay Loveless <claykillersoft.com> wrote:
>
> On Sep 18, 2007, at 5:56 PM, Joe Stump wrote:
>
> > Now, both of these services have both public'ish
API keys and
> > secrets. The problem I have is publicly exposing
my API keys and
> > secrets via my package's tests. With Facebook it's
minimized
> > because you have to add the Services_Facebook PEAR
application to
> > your profile (I've created a junk account
specifically for the
> > tests), but Flickr is a bit more open I think,
though you'd need to
> > give the package access to your Flickr account
before write
> > operations could happen.
> >
> > I suppose I could create a junk Flickr account and
do the same
> > thing I did with Facebook ...
> >
> > Thoughts?
>
> My plan for this sort of thing -- I'm running into a
similar issue
> with unit tests for the new VersionControl_SVN package
-- is to have
> a tests directory that contains a README, with
instructions on how
> the tests directory needs to have
"sensitive.ini" or some other sort
> of config file in it.
>
> That README defines what the config file needs to have,
such as keys,
> shared secrets, etc. in order for tests to run
properly.
>
> Then you commit and release the package with everything
*but* your
> sensitive config information. Those who really want to
run tests can
> read the README and configure their own local
environment accordingly
> to run the tests.
>
> Might be worth an RFC for a
"test/secrets.ini" proposal, so that
> there's one place that all packages which have tests
that need some
> sort of account information can look for that info.
>
> secrets.ini:
>
> [VersionControl_SVN]
> login: clay
> password: foo
>
> [Services_Flickr]
> api_key: 1234456778889
>
> [Services_Facebook]
> apikey: 12356789
>
> ... and so on. The test can load parse_ini_file('tests/
> secrets.ini', true) and pick out the credentials needed
by the package.
>
> Given the rise of web service packages that need
exactly this sort of
> thing, this sounds better to me with every keystroke.

>

It's not just web packages.  MDB2 of
course requires DB credentials
and a database for testing. It uses a test_setup.php which
must be
edited created (from test_setup.dist) before running tests.


-- 
Justin Patrin

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php