Hello Mario,
Just one comment:
At 06:32 04/08/24 +0200, Mario Salzer wrote:
This vendor tree MIME type registration application discusses the data
format emitted by PHPs "serialize()". It is no longer in use only within
there; some independent implementations exist (evtl. becoming an exchange
forma
This vendor tree MIME type registration application discusses the data
format emitted by PHPs "serialize()". It is no longer in use only within
there; some independent implementations exist (evtl. becoming an exchange
format).
Now that doesn't require a MIME Type per se, but people also started
pu
Thanks :)
At 10:53 AM 8/24/2004 +1000, Dave Barr wrote:
Andi Gutmans wrote:
andiMon Aug 23 16:18:11 2004 EDT
Modified files:
/php-srcNEWS Log:
- NEWS
http://cvs.php.net/diff.php/php-src/NEWS?r1=1.1799&r2=1.1800&ty=u
Index: php-src/NEWS
diff -u php-src/NEWS:1.1799 php-src/N
Andi Gutmans wrote:
andiMon Aug 23 16:18:11 2004 EDT
Modified files:
/php-src NEWS
Log:
- NEWS
http://cvs.php.net/diff.php/php-src/NEWS?r1=1.1799&r2=1.1800&ty=u
Index: php-src/NEWS
diff -u php-src/NEWS:1.1799 php-src/NEWS:1.1800
--- php-src/NEWS:1.1799 Mon
On Aug 23, 2004, at 4:04 PM, Chris Shiflett wrote:
--- Adam Q <[EMAIL PROTECTED]> wrote:
The database needs a password otherwise it is just too much of a
security risk.
Based on my observation of the conversation you've been having, I think
you might be making things too complex on yourself. Th
--- Adam Q <[EMAIL PROTECTED]> wrote:
> The database needs a password otherwise it is just too much of a
> security risk.
Based on my observation of the conversation you've been having, I think
you might be making things too complex on yourself. This database is just
a file. So, think of havi
Ilia Alshanetsky wrote:
An Sqlite database is nothing more then a binary file, and you should treat it
such. If you do not want to have people being able to download it, do not put
it inside a web accessible directory.
Or, don't forget the existance of .htaccess files. Want to block sqlite
file
This one time, at band camp, Derick Rethans <[EMAIL PROTECTED]> wrote:
> > I would like to distribute a tarball for a PHP application that can be
> > dropped into someones website along the same lines as PostNuke,
> > phpMyAdmin etc (you get the idea).
>
> Perhaps this is exactly why PostNuke is
On Mon, Aug 23, 2004 at 11:10:16AM -0700, Rasmus Lerdorf wrote:
> On Mon, 23 Aug 2004, Michael Spector wrote:
> > I'm "translating" some function, that recieves a pointer to structure of
> > this type:
> >
> > struct {
> > char * text;
> > char ** value;
> > int flags;
> > };
>
> This
On Mon, 23 Aug 2004, Michael Spector wrote:
> I'm "translating" some function, that recieves a pointer to structure of
> this type:
>
> struct {
> char * text;
> char ** value;
> int flags;
> };
This looks like a string, an array and an integer to me. So just pass
that. Or an array o
Hi,
I'm "translating" some function, that recieves a pointer to structure of
this type:
struct {
char * text;
char ** value;
int flags;
};
and I'm get stuck here, thinking of a legal way how to pass the list of
structures to my PHP function. I thought to pass it in this way:
myfunc
If all you want to do is use an already implemented one just do this:
php_stream *stream;
php_stream_filter *filter;
zval *arguments = NULL; /* Populate this with value(s) appropriate to the
filter */
stream = php_stream_open_wrapper(.blah blah blah.);
filter = php_stream_filter
On August 23, 2004 12:34 pm, Zeev Suraski wrote:
> The point is that hosting companies, especially those using chroot, have to
> make sure that they don't force their users to store the database files in
> web-accessible locations, since the server is most probably designed to be
> able to serve fi
At 17:16 23/08/2004, Ilia Alshanetsky wrote:
Here is the simple truth, if you are using a shared hosting solution that is
not VPS (Virtual Private Server) it would be relatively trivial for other
users of the system to access any file that the webserver has access to.
The point is that hosting comp
There are a lot of ways being a stupid programmer can give you an
insecure website. Saying that just because someone is too stupid to
properly lock down their data store (put outside the web root, run PHP
with proper perms, etc.), makes PHP/SQLite themselves insecure, is like
putting coffee on
can anyone give a hint as to how to use stream filters from an extension ?
i have to parse input files which may be in a variety of encodings (mainly
UTF8), and processing is done internally in UTF16.
i noticed that there is an iconv filter, but i havent a clue (even after
googling) of how to use
Here is the simple truth, if you are using a shared hosting solution that is
not VPS (Virtual Private Server) it would be relatively trivial for other
users of the system to access any file that the webserver has access to. Now,
because webserver will need access privileges to various PHP config
On 23/08/2004, at 9:22 PM, [EMAIL PROTECTED] wrote:
Adam Q <[EMAIL PROTECTED]> writes:
I think encryption for SQLite is essential for PHP. Without it, it
makes it
almost useless in a webscripting language. Suppose you wanted to
create an
open source, easily portable, file based guestbook in PHP.
Adam Q wrote:
Putting the files outside the document root is secure, I agree... But
how can you be sure of this with an open source application (as opposed
to internally developed)? People are likely to drop your application
anywhere in their web tree they think it fits.
you document the problem
On Monday 23 August 2004 14:27, Zeev Suraski wrote:
[...]
>
> Hrm, well, it's a very bad idea to put the database anywhere under the
> document root, because then you'd obviously be serving it for everyone to
> download. Encryption or no encryption, that's a very bad idea.
> Instead, you should p
On Mon, 23 Aug 2004, Adam Q wrote:
> > Hrm, well, it's a very bad idea to put the database anywhere under the
> > document root, because then you'd obviously be serving it for everyone
> > to download. Encryption or no encryption, that's a very bad idea.
> > Instead, you should place the database
On 23/08/2004, at 8:27 PM, Zeev Suraski wrote:
At 15:18 23/08/2004, Adam Q wrote:
On 23/08/2004, at 7:24 PM, Zeev Suraski wrote:
At 13:56 23/08/2004, Adam Q wrote:
Dear all,
I feel I may have uncovered a potentially large difficulty for the
adoption of SQLite.
I think encryption for SQLite is ess
Adam Q <[EMAIL PROTECTED]> writes:
> I think encryption for SQLite is essential for PHP. Without it, it makes it
> almost useless in a webscripting language. Suppose you wanted to create an
> open source, easily portable, file based guestbook in PHP. I would never use
> SQLLite under the current
On Mon, 2004-08-23 at 12:24, Zeev Suraski wrote:
> I think that most database setups in general don't keep their information
> encrypted, and the reasons they use username/password pairs is mainly
> because (a) they're designed to serve multiple users (at the OS level) on
> the same machine, an
At 15:18 23/08/2004, Adam Q wrote:
On 23/08/2004, at 7:24 PM, Zeev Suraski wrote:
At 13:56 23/08/2004, Adam Q wrote:
Dear all,
I feel I may have uncovered a potentially large difficulty for the
adoption of SQLite.
I think encryption for SQLite is essential for PHP. Without it, it makes
it almost
On 23/08/2004, at 7:24 PM, Zeev Suraski wrote:
At 13:56 23/08/2004, Adam Q wrote:
Dear all,
I feel I may have uncovered a potentially large difficulty for the
adoption of SQLite.
I think encryption for SQLite is essential for PHP. Without it, it
makes it almost useless in a webscripting language
At 13:56 23/08/2004, Adam Q wrote:
Dear all,
I feel I may have uncovered a potentially large difficulty for the
adoption of SQLite.
I think encryption for SQLite is essential for PHP. Without it, it makes
it almost useless in a webscripting language.
Why is that? You would have to gain file-lev
Dear all,
I feel I may have uncovered a potentially large difficulty for the
adoption of SQLite.
I think encryption for SQLite is essential for PHP. Without it, it
makes it almost useless in a webscripting language.
Suppose you wanted to create an open source, easily portable, file
based guestb
On Mon, Aug 23, 2004 at 11:01:38AM +0200, Derick Rethans wrote:
> Committed, thanks!
Thanks. #27791 can be closed now.
joe
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Mon, 23 Aug 2004, Joe Orton wrote:
> On Mon, Aug 23, 2004 at 09:48:06AM +0200, Derick Rethans wrote:
> > On Mon, 23 Aug 2004, Joe Orton wrote:
> >
> > > This fixes the 2.0 SAPI build against HEAD of httpd-2.0:
> >
> > Can you please send it as an attachment (extension .txt), otherwise it
> > ge
On Mon, Aug 23, 2004 at 09:48:06AM +0200, Derick Rethans wrote:
> On Mon, 23 Aug 2004, Joe Orton wrote:
>
> > This fixes the 2.0 SAPI build against HEAD of httpd-2.0:
>
> Can you please send it as an attachment (extension .txt), otherwise it
> get's garbled when saving.
Sure.
Index: sapi/apache2
On Mon, 23 Aug 2004, Joe Orton wrote:
> This fixes the 2.0 SAPI build against HEAD of httpd-2.0:
Can you please send it as an attachment (extension .txt), otherwise it
get's garbled when saving.
regards,
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
--
P
This fixes the 2.0 SAPI build against HEAD of httpd-2.0:
1. pick up correct names for ap[ru]-config from apxs
2. pick up --cppflags etc from apr-config to ensure that
-D_LARGEFILE64_SOURCE is used where necessary (that's bug #27761)
since APR now has large file support
(tested to not break the bu
33 matches
Mail list logo
