headers
Wolfram Kriesing | 1 Jun 2002 01:36
Picon

Re: Mail_Mime sending HTML-mail example

Richard Heyes wrote:

>Wolfram Kriesing <lists <at> kriesing.de> wrote:
>
>  
>
>>Markus Fischer wrote:
>>    
>>
>>>    Hi,
>>>
>>>    do you *really* need the images being inline?
>>>
>>>    I haven't seen a problem yet with sending HTML mails (for
>>>    newsletters, e.g.) which reference the images with an
>>>    absolute URL: <img src="http://host/images/spacer.gif" width
>>>      
>>>
>>that's the problem, i do need them to be inline :-(
>>    
>>
>
>A copy of the source of one of the emails might help.
>
>  
>
sorry guys, my alarm was invain
i tested it with kmail as i wrote - that was the problem :-)

wolfram
(Continue reading)

Permalink | Reply | 0 comments |
headers
Vincent Blavet | 1 Jun 2002 15:34

Re: testing pear part one


"robert janeczek" <rashid <at> ds.pg.gda.pl> wrote in message news:20020531214141.35891.qmail <at> pb1.pair.com...
> hi
> i have an exam tomorrow, so i wanted to find myself something else to do :)
> i tried to use all (?) the pear classes. now you can see how it looks from
> begginers look. i`ll point all the traps i encountered on my way. this can
> be useful for future doc releases. i use win2k, so there will be some hints
> and bugs showing up only on this platform. sorry for the length of this
> message i hope you know how to cut posts while answering ;) i`m sure there
> are many my mistakes, i hope that thanks to them you`ll know what are the
> usual problems and what tips are needed in documentation. so - don`t be mad
> at me :) i`m not using advanced features - i just wanted to make classes
> work on my mashine. today - part one - two first classes (i choose classes
> alphabeticaly). stay tuned for next parts...
> 
> test platform:
> System Windows NT 5.0 build 2195
> SERVER_SOFTWARE Apache/1.3.22 (Win32) PHP/4.2.1
> php 'from the box' with some changes in php.ini:
> - register_globals = on (yes, i know...)
> - changed include path and extensions path
> - apopriate extensions loaded (more information with classes using them)
> 
> pear downloaded from cvs today, about 16.00 cet. installed manually.
> 
> 1. Archive/Tar.php
> Tar.php,v 1.1 2002/05/27 21:48:36
> 
> extensions:
> ZLib Support enabled
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bertrand Mansion | 1 Jun 2002 11:53
Gravatar

Re: PEAR_RemoteCache.php - cached XMLrpc

<alan <at> akbkhome.com> wrote :

> Attached (hopefully) is a Class for Cached retrieval of the package data
> (although it could do other stuff)..

Yo Yo Yo ! I will have a look at it this weekend.
Thanks Alan.

Bertrand Mansion
Mamasam

--

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Permalink | Reply | 0 comments |
headers
Martin Jansen | 1 Jun 2002 12:06
Picon

Re: Re: testing pear part one

On Sat, 1 Jun 2002 00:00:18 +0200, robert janeczek wrote:

>during test Auth feature request came to my mind: as we all know - in many
>cases knowing that an user was able to log into our site isn`t enough. very
>often basic auth system is extended with access levels. how about adding
>this feature to Auth class?

This has been discussed before and we came to the conclusion that
handling permissions isn't the right job for an authentication package.
Something like this should be put into an own package.

- Martin
-- 
  Martin Jansen, <mail <at> martin-jansen.de>
  http://www.martin-jansen.de/

--

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Permalink | Reply | 0 comments |
headers
robert janeczek | 1 Jun 2002 12:32
Picon
Picon
Picon

testing pear part two


3. Auth/Auth_HTTP.php
Auth_HTTP.php,v 1.5 2001/12/11 19:45:36

docs:
- almost no documentation, but not much is needed. i think that example for
this class should be the same as for Auth class - then the similarity is
best shown

4. Benchmark/*
no problems

5. Cache/Application.php
Application.php,v 1.3 2002/05/23 14:18:40

strange things:
- by default constructor is called with something like this:
$container_options = array('cache_dir' => '/tmp/' inside. i was suprised -
why isn`t session.save_path used in this case? this creates to much mess - i
had session files in two different directories around my disk.

6. Cache/DB.php
DB.php,v 1.3 2002/05/23 14:18:40

docs:
- almost nothing. sweeping through code is needed

strange things:
- the same as above - array('cache_dir'       => '.' in constructor default
call - third place to store session data
(Continue reading)

Permalink | Reply | 0 comments |
headers
robert janeczek | 1 Jun 2002 16:00
Picon
Picon
Picon

Re: testing pear part one

> Hey guy, start to learn - I know what I'm talking about :).

failed :] np-completness, it is 3rd year i try to pass it, i think i`ll
finish my studies and it still won`t be passed ;)

> Good point. I did not know until now that it's necessary (/me has no
> Windows PHP).

i`m to lazy to switch to linux ]:)

> It's still in php4/pear/File/.

yes, no i see it :)

> It looks like isLocked() has been added by Mika Tuupola in revision
> 1.10, which apparently didn't make it's way into PHP 4.2.1 :(.
>
> Yup, it should be actually :). Please get the latest version of
> File/Passwd.php from CVS and try again.

so i tried :)

file: i downloaded latest file/passwd.php from cvs [Passwd.php,v 1.10
2002/04/17 14:41:37] and there are some serious problems:
Auth_Container_File::Auth_Container_File() constructs new file_passwd object
with lock set to 0 (no lock file is created), then 'locked' variable is set
from code, but it doesn`t work as it seems to - someone surely wanted to
crate lock file, but only by setting variable he gets nothing except file
access errors. line 65 should be changed to '$this->pwfile->lock();' - this
CREATES file and locks it. constructors end lines changed to this:
(Continue reading)

Permalink | Reply | 4 comments |
headers
Martin Jansen | 1 Jun 2002 12:05
Picon

Re: testing pear part one

On Fri, 31 May 2002 23:37:20 +0200, robert janeczek wrote:

>i have an exam tomorrow, so i wanted to find myself something else to do :)

Hey guy, start to learn - I know what I'm talking about :).

>- register_globals = on (yes, i know...)

It would be nice to see if *all* PEAR packages are register_globals
safe. Has anyone made some tests yet?

>- should add a note that windows users need to change default
>session.save_path setting in php.ini - its quite confusing first time you
>see a message about it :)

Good point. I did not know until now that it's necessary (/me has no
Windows PHP).

>- should add basic sql code creating table for default Auth/Container/DB.php
>settings - especially minimum field lenght for password column needs to be
>said, i created 20 chars long field and nothing worked well because encoded
>password didn`t fit

This has been suggested some time before, but I did not get around to
do it yet.

>file: hmmmm i couldn`t find File/Passwd.php in newest cvs contents 

It's still in php4/pear/File/.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Alan Knowles | 1 Jun 2002 11:02
Favicon
Gravatar

PEAR_RemoteCache.php - cached XMLrpc

Attached (hopefully) is a Class for Cached retrieval of the package data 
(although it could do other stuff)..

Logical overview:

PEAR server creates a cache of 'Package.listAll' as 
/xmlrpc/Package.listAll.xml every time a package is released.

The User uses the installer to do a
pear remote-list

1. it does a http HEAD command to access the HEADER details for that file.
2. it compares the  modification time (from the http headers) with the 
cached file (if it exists).
if they are current file is newer it does a full get request on the HTTP 
file.
downloads it to {php_dir}/.registry/Package.listAll.xml

3. it loads the data from the cache -> and proccess it the same way that 
Remote used to...

--------------------------
This stuff could be merged with PEAR_Remote / PEAR_Common - as it is 
basically a cut and paste with a few mods..

call : rename calllCached ?
_fetchHead/_fetchBody ..

add a _downloadCallback to Remote
(Continue reading)

Permalink | Reply | 3 comments |
headers
Martin Jansen | 1 Jun 2002 18:18
Picon

Re: testing pear part one

On Sat, 1 Jun 2002 16:00:50 +0200, robert janeczek wrote:

>file: i downloaded latest file/passwd.php from cvs [Passwd.php,v 1.10
>2002/04/17 14:41:37] and there are some serious problems:
>Auth_Container_File::Auth_Container_File() constructs new file_passwd object
>with lock set to 0 (no lock file is created), then 'locked' variable is set
>from code, but it doesn`t work as it seems to - someone surely wanted to
>crate lock file, but only by setting variable he gets nothing except file
>access errors. line 65 should be changed to '$this->pwfile->lock();' - this
>CREATES file and locks it. constructors end lines changed to this:
>  $this->pwfile->lock();//primary locking
>        $this->pwfile->close();//this saves file and UNLOCKS!
>  $this->pwfile->lock();//this lock is needed to operate properly on data
>(adding users etc)
>my point is that Auth/Container/file.php has many more places like this
>where lock isn`t being made where it is needed. code reanalyzing is needed -
>for now it doesn`r seem to work without changes in code, i fixed some
>methods by myself - i can commit them, i just wanted to know if someone has
>an explanation on this locking mess :)

It looks like Mika invested a lot of work into the file container.
Maybe he can have a look at this?

- Martin
-- 
  Martin Jansen, <mail <at> martin-jansen.de>
  http://www.martin-jansen.de/

--

-- 
PEAR Development Mailing List (http://pear.php.net/)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Tomas V.V.Cox | 1 Jun 2002 19:32

Re: Anybody working on SSO class/project ???

Nicolas Hoizey wrote:
> 
> Hi everybody,
> 
> I'm currently trying to design a PHP SSO (Single Sign On) application,
> and would like to know if anybody has already done anything.
> 
> I haven't found any SSO project in PHP yet, but I think it should be
> part of the Auth package. Some people tried to design a User class a
> while ago, but I don't know if it has given anything.

I don't think it should be part of Auth, I'd say to use it as part of
the "User" thing.

> The simple way would be to patch all application so that they use the
> same auth application, but it would break compatibility with those
> application updates.

I can think on a pluggable architecture where each application provides
a file with common functions like: addUser(), removeUser(), etc. From
the central user admin, a call to the main addUser() function could call
all the app specific addUser() funcs.

I guess that this solution is not a real SSO system, it's more a
"uniform way for handling users" but gives a solution to the "disspersed
auth systems" problem. Each application needs too specific data and I
finally get to the point where is really difficult (for not saying
imposible) to have a unique "container" of user data.

Then, if an app would like to support our SSO, they would only have to
(Continue reading)

Permalink | Reply | 10 comments |

Gmane