|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
php-general-digest-help
lists.php.net
Date: Mon May 19 2008 - 14:05:36 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
php-general Digest 19 May 2008 19:05:36 -0000 Issue 5468
Topics (messages 274501 through 274536):
Trying to install imagick PECL module
274501 by: mike
274502 by: Chris
Re: problem with htmlspecialchars in version5.2.5
274503 by: Sanjeev N
Re: Improving development process / help with developer setup
274504 by: robert mena
274506 by: Richard Heyes
274507 by: Zoltán Németh
274508 by: Jason Pruim
274510 by: Richard Heyes
274515 by: robert mena
274516 by: robert mena
274521 by: Brady Mitchell
274522 by: Zoltán Németh
Re: Semi-OT: PHP Login with client security
274505 by: Eric Butera
274509 by: Wolf
274511 by: Bastien Koert
274512 by: tedd
274523 by: Per Jessen
274524 by: Per Jessen
274525 by: robert
274526 by: Per Jessen
274528 by: Richard Heyes
274529 by: Eric Butera
274536 by: Wolf
Re: XML file locking
274513 by: Iv Ray
274514 by: bruce
274517 by: Iv Ray
274520 by: bruce
Dead code
274518 by: Aschwin Wesselius
274519 by: Eric Butera
pg_update and PGSQL_DML_STRING
274527 by: J. Manuel Velasco - UBILIBET
Still not getting Includes right.
274530 by: Tyson Vanover
274531 by: Jim Lucas
274532 by: Tyson Vanover
274533 by: robert
274534 by: Tyson Vanover
Re: Threads PHP
274535 by: Thiago Pojda
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscribe
lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscribe
lists.php.net
To post to the list, e-mail:
php-general
lists.php.net
----------------------------------------------------------------------
attached mail follows:
It doesn't appear to -need- this MagickWand stuff, yet configure keeps
failing on it.
Anyone here use it, know for sure? Thanks. It looks and it sees
imagemagick and such, but why it -requires- this API is confusing me.
root
local:/usr/src/build/imagick-2.2.0b2# ./configure
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for a sed that does not truncate output... /bin/sed
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc and cc understand -c and -o together... yes
checking for system library directory... lib
checking if compiler supports -R... no
checking if compiler supports -Wl,-rpath,... yes
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking for PHP prefix... /usr/local
checking for PHP includes... -I/usr/local/include/php
-I/usr/local/include/php/main -I/usr/local/include/php/TSRM
-I/usr/local/include/php/Zend -I/usr/local/include/php/ext
-I/usr/local/include/php/ext/date/lib
checking for PHP extension directory...
/usr/local/lib/php/extensions/no-debug-non-zts-20060613
checking for PHP installed headers prefix... /usr/local/include/php
checking for re2c... no
configure: WARNING: You will need re2c 0.12.0 or later if you want to
regenerate PHP parsers.
checking for gawk... gawk
checking whether to enable the imagick extension... yes, shared
checking whether to enable the imagick GraphicsMagick backend... no
checking ImageMagick MagickWand API configuration program...
configure: error: not found. Please provide a path to
MagickWand-config or Wand-config program.
root
local:/usr/src/build/imagick-2.2.0b2#
attached mail follows:
mike wrote:
> It doesn't appear to -need- this MagickWand stuff, yet configure keeps
> failing on it.
I guess it really does need the api stuff then ;)
Which parts of imagemagick have you got installed or how did you install
imagemagick? for configuring php (and other software) you need the
headers as well as the main package (if you're installing from a package
based system).
--
Postgresql & php tutorials
http://www.designmagick.com/
attached mail follows:
which special characters dint converted?
this function converts only few special characters. try to use htmlentities
function instead
--
Regards,
Sanjeev
http://www.sanchanworld.com | http://webdirectory.sanchanworld.com - submit
your site
On 5/17/08, It flance <itmaqurfe
yahoo.com> wrote:
>
> Hi,
>
> this statement:
> echo nl2br(htmlspecialchars($row['jobdescription'], ENT_QUOTES, 'UTF-8'));
>
> works for php4.3.10 but not for php5.2.5
>
> I am wondering if i am missing something.
>
> Thank you
>
>
>
>
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
attached mail follows:
Hi,
Thanks for all answers. Please let me add that I do use CVS (migrating to
SVN) and the reason to use samba is that doing this allows the developer
machine (windows) to access the shares hosted in a linux server so when
he/she tests it will be run in the 'same' environment that the staging and
production servers and because in order to assure browser compatibility they
have to test from firefox/IE.
So, in order to allow phpunit to be ran, have the firefox/IE support and use
xdebug I have two basic options:
a) stay with windows, install XAMPP (or any other all-in-one). And live
with the fact that some things will have to be taken care of (such as
PATH differences between unix/windows)
b) switch to linux with the development stack, enable a windows server to be
connected from rdesktop so they can test the IE
In both cases I'll have extra work in order to maintain the developer's
machine somewhat synchronized with the production server.
Am I missing a third/fourth (better) etc option?
thanks.
On Sat, May 10, 2008 at 8:44 PM, Gabriel Sosa <sosagabriel
gmail.com> wrote:
> I suggest you if you are running live on linux, then developing on
> linux, could be the same dist or not..
> but definitely don't mix OS, because the extensions could fail, etc.
> one big issue it's the case insensitive in windows.
>
> definitely some version control system such as SVN or GIT
>
> you can use Hudson for continuous integration
>
> and selenium for automatics QA test over browsers
>
> again, try to don't mix OS.
>
> saludos
>
> gabriel
>
> On Sat, May 10, 2008 at 1:44 PM, David Otton <david
otton.org> wrote:
> > 2008/5/10 robert mena <robert.mena
gmail.com>:
> >
> >> I am looking for tips regarding improving the development process. I'll
> >> explain my current setup and please feel free to comment.
> >>
> >> My developers all use windows + eclipse PDT, the workspace is hosted
> (via
> >> samba) in a Linux server with Apache/PHP/MySQL. I am in the process of
> >> adopting Unit testing (PHPUnit2) and debug (Xdebug) so I have concerns
> about
> >> how to property use this.
> >>
> >> For example, in my current setup I'd have to enable SSH so they could
> run
> >> the tests from the command line in the development server, but I am not
> sure
> >> if I could remotely use Xdebug.
> >
> > Your description (specifically, Samba) suggests that you're not using
> > source control. If you want to go for TDD (I don't know that you do,
> > but IMO it's a good direction to move in) I would suggest a
> > three-server setup - dev, staging and live.
> >
> > The dev server(s) are where you work. One per developer. Once you're
> > happy with your code and your tests, you commit your changes to source
> > control. This is where it gets clever. You can use pre- and
> > post-commit hooks to run an automated build process that pushes the
> > changes to a staging server, automatically runs the unit tests, and
> > accepts/rejects the commits based on the test results. You can even
> > lint the code, and reject anything that isn't in the house style.
> >
> > With larger projects, where an entire publish-and-test on each commit
> > becomes impractical, you can just run the build process and unit tests
> > every n hours, and mail out the results.
> >
> > Publishing to the live server is simply a matter of running the build
> > scripts with a different destination.
> >
> > On top of all that, run an issue tracker. /Everything/ goes in the
> > issue tracker, bugs, features, whatever. When you make a commit, that
> > commit should be closing an issue in the issue tracker (via commit
> > hooks again). That way you can track each change that's been made back
> > to its reason.
> >
> > All of this is opinion, of course, there's no Right Way. Just take
> > what's useful to you.
> >
> > --
> > PHP General Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>
>
>
> --
> Los sabios buscan la sabiduría; los necios creen haberla encontrado.
> Gabriel Sosa
>
attached mail follows:
> Thanks for all answers. Please let me add that I do use CVS (migrating to
> SVN) and the reason to use samba is that doing this allows the developer
> machine (windows) to access the shares hosted in a linux server so when
> he/she tests it will be run in the 'same' environment that the staging and
> production servers and because in order to assure browser compatibility they
> have to test from firefox/IE.
If you only have a small number of developers, you could do away with
Samba completely and use SftpDrive, which allows you to map a drive to
an SFTP account (essentially the same as an SSH account).
http://www.phpguru.org/sftpdrive
--
Richard Heyes
+----------------------------------------+
| Access SSH with a Windows mapped drive |
| http://www.phpguru.org/sftpdrive |
+----------------------------------------+
attached mail follows:
> Hi,
> Thanks for all answers. Please let me add that I do use CVS (migrating
> to
> SVN) and the reason to use samba is that doing this allows the developer
> machine (windows) to access the shares hosted in a linux server so when
> he/she tests it will be run in the 'same' environment that the staging and
> production servers and because in order to assure browser compatibility
> they
> have to test from firefox/IE.
>
> So, in order to allow phpunit to be ran, have the firefox/IE support and
> use
> xdebug I have two basic options:
> a) stay with windows, install XAMPP (or any other all-in-one). And live
> with the fact that some things will have to be taken care of (such as
> PATH differences between unix/windows)
> b) switch to linux with the development stack, enable a windows server to
> be
> connected from rdesktop so they can test the IE
>
> In both cases I'll have extra work in order to maintain the developer's
> machine somewhat synchronized with the production server.
>
> Am I missing a third/fourth (better) etc option?
why not switch everything to linux and run IE in wine or vmware on the
developer's machine? that way you don't have to maintain windows machines
at all
greets,
Zoltán Németh
>
> thanks.
>
> On Sat, May 10, 2008 at 8:44 PM, Gabriel Sosa <sosagabriel
gmail.com>
> wrote:
>
>> I suggest you if you are running live on linux, then developing on
>> linux, could be the same dist or not..
>> but definitely don't mix OS, because the extensions could fail, etc.
>> one big issue it's the case insensitive in windows.
>>
>> definitely some version control system such as SVN or GIT
>>
>> you can use Hudson for continuous integration
>>
>> and selenium for automatics QA test over browsers
>>
>> again, try to don't mix OS.
>>
>> saludos
>>
>> gabriel
>>
>> On Sat, May 10, 2008 at 1:44 PM, David Otton <david
otton.org> wrote:
>> > 2008/5/10 robert mena <robert.mena
gmail.com>:
>> >
>> >> I am looking for tips regarding improving the development process.
>> I'll
>> >> explain my current setup and please feel free to comment.
>> >>
>> >> My developers all use windows + eclipse PDT, the workspace is hosted
>> (via
>> >> samba) in a Linux server with Apache/PHP/MySQL. I am in the process
>> of
>> >> adopting Unit testing (PHPUnit2) and debug (Xdebug) so I have
>> concerns
>> about
>> >> how to property use this.
>> >>
>> >> For example, in my current setup I'd have to enable SSH so they could
>> run
>> >> the tests from the command line in the development server, but I am
>> not
>> sure
>> >> if I could remotely use Xdebug.
>> >
>> > Your description (specifically, Samba) suggests that you're not using
>> > source control. If you want to go for TDD (I don't know that you do,
>> > but IMO it's a good direction to move in) I would suggest a
>> > three-server setup - dev, staging and live.
>> >
>> > The dev server(s) are where you work. One per developer. Once you're
>> > happy with your code and your tests, you commit your changes to source
>> > control. This is where it gets clever. You can use pre- and
>> > post-commit hooks to run an automated build process that pushes the
>> > changes to a staging server, automatically runs the unit tests, and
>> > accepts/rejects the commits based on the test results. You can even
>> > lint the code, and reject anything that isn't in the house style.
>> >
>> > With larger projects, where an entire publish-and-test on each commit
>> > becomes impractical, you can just run the build process and unit tests
>> > every n hours, and mail out the results.
>> >
>> > Publishing to the live server is simply a matter of running the build
>> > scripts with a different destination.
>> >
>> > On top of all that, run an issue tracker. /Everything/ goes in the
>> > issue tracker, bugs, features, whatever. When you make a commit, that
>> > commit should be closing an issue in the issue tracker (via commit
>> > hooks again). That way you can track each change that's been made back
>> > to its reason.
>> >
>> > All of this is opinion, of course, there's no Right Way. Just take
>> > what's useful to you.
>> >
>> > --
>> > PHP General Mailing List (http://www.php.net/)
>> > To unsubscribe, visit: http://www.php.net/unsub.php
>> >
>> >
>>
>>
>>
>> --
>> Los sabios buscan la sabiduría; los necios creen haberla encontrado.
>> Gabriel Sosa
>>
>
attached mail follows:
On May 19, 2008, at 8:45 AM, Zoltán Németh wrote:
>> Hi,
>> Thanks for all answers. Please let me add that I do use CVS
>> (migrating
>> to
>> SVN) and the reason to use samba is that doing this allows the
>> developer
>> machine (windows) to access the shares hosted in a linux server so
>> when
>> he/she tests it will be run in the 'same' environment that the
>> staging and
>> production servers and because in order to assure browser
>> compatibility
>> they
>> have to test from firefox/IE.
>>
>> So, in order to allow phpunit to be ran, have the firefox/IE
>> support and
>> use
>> xdebug I have two basic options:
>> a) stay with windows, install XAMPP (or any other all-in-one). And
>> live
>> with the fact that some things will have to be taken care of (such as
>> PATH differences between unix/windows)
>> b) switch to linux with the development stack, enable a windows
>> server to
>> be
>> connected from rdesktop so they can test the IE
>>
>> In both cases I'll have extra work in order to maintain the
>> developer's
>> machine somewhat synchronized with the production server.
>>
>> Am I missing a third/fourth (better) etc option?
>
> why not switch everything to linux and run IE in wine or vmware on the
> developer's machine? that way you don't have to maintain windows
> machines
> at all
Or depending on your budget, Switch the developers to Macintosh
computers, install windows via parallels, and then you can test in Mac/
Unix/Windows all from 1 computer :)
--
Jason Pruim
Raoset Inc.
Technology Manager
MQC Specialist
3251 132nd ave
Holland, MI, 49424-9337
www.raoset.com
japruim
raoset.com
attached mail follows:
> Or depending on your budget, Switch the developers to Macintosh
> computers, install windows via parallels, and then you can test in
> Mac/Unix/Windows all from 1 computer :)
And watch everyone quit... :-)
--
Richard Heyes
+----------------------------------------+
| Access SSH with a Windows mapped drive |
| http://www.phpguru.org/sftpdrive |
+----------------------------------------+
attached mail follows:
Hi Zoltan,
If the windows would be used just for IE I think it's cheaper to have one
windows machine (server 2003/2008), have the users connect via terminal
service (rdesktop). I think it's easier than having to install/maintain
than multiple windows installations, even if it is a virtual machine.
>
> why not switch everything to linux and run IE in wine or vmware on the
> developer's machine? that way you don't have to maintain windows machines
> at all
>
> greets,
> Zoltán Németh
>
>
attached mail follows:
Unfortunately this is not an option due to budget :) I use Mac myself (with
VMWare fusion) but would not be feasible to depoly this with all the devel
team.
>>
> Or depending on your budget, Switch the developers to Macintosh computers,
> install windows via parallels, and then you can test in Mac/Unix/Windows all
> from 1 computer :)
>
>
attached mail follows:
On May 19, 2008, at 520AM, robert mena wrote:
> So, in order to allow phpunit to be ran, have the firefox/IE support
> and use
> xdebug I have two basic options:
> a) stay with windows, install XAMPP (or any other all-in-one). And
> live
> with the fact that some things will have to be taken care of (such as
> PATH differences between unix/windows)
This is what we do where I work. XAMPP has been configured and put
into Perforce (our revision control system) so anytime a change is
made or we decide to update to a new version of XAMPP, all the devs
need to do is grab the latest version. This makes it very nice when
people need help setting something up as we all have the exact same
setup.
We've created some template vhost files for setting up new sites, so
getting a new site setup on the local machine is much easier now,
especially for those devs who still don't know all that much about
Apache. Once a vhost file is working properly, we check it into
perforce so that if we need to reinstall XAMPP later, or if someone
else needs to work on the site it's as simple as getting the latest
version of the file from perforce.
For the path differences, we are starting to move the include_path
setting out of .htaccess where we've been setting it and into the
vhost configuration for the site. Of course this also needs to be done
on the server, but it only takes a couple minutes to do.
I'd much rather be using a Mac or Linux at work and using vmware for
IE testing, but that's not up to me.
> b) switch to linux with the development stack, enable a windows
> server to be
> connected from rdesktop so they can test the IE
I would get feedback from your devs about this before making such a
drastic switch. Personally, I'd love to ditch windows on my box at
work, but I know that some of the devs I work with would not be very
happy about that. It also depends on what software your devs are
using, and if it's available on Linux. Sure, there are alternatives to
everything, but learning to use and becoming efficient with an
alternative isn't nearly as productive as continuing to use the same
tools.
Brady
attached mail follows:
> Hi Zoltan,
>
> If the windows would be used just for IE I think it's cheaper to have one
> windows machine (server 2003/2008), have the users connect via terminal
> service (rdesktop). I think it's easier than having to install/maintain
> than multiple windows installations, even if it is a virtual machine.
one server is cheaper than multiple vmware windozes, but multiple wine
instances with IE are free. ;)
greets,
Zoltán Németh
>
>
>>
>> why not switch everything to linux and run IE in wine or vmware on the
>> developer's machine? that way you don't have to maintain windows
>> machines
>> at all
>>
>> greets,
>> Zoltán Németh
>>
>>
>
attached mail follows:
On Mon, May 19, 2008 at 1:14 AM, Tim Thorburn <immortal
nwconx.net> wrote:
> Hi all,
>
> Having a slight problem with a demo I gave at a clients last week - looking
> for a little advise. Part of my demo involved a password protected area -
> the simplified process is: client enters password on login page > if
> login/password match encrypted database, PHP session is created, form
> forwards to a secured area > secured area checks to make sure PHP session is
> valid > if valid display content, if not, return to login screen.
>
> This procedure is what I've used for many years, tested on a variety of
> servers and connections. It works. During the demo with my client, I was
> able to enter login/password info, the PHP session was created - however the
> screen would not forward to the secured area. Instead I was pretended with
> a blank screen (client only has an outdated/non-updated version of IE6). If
> I were to type in the URL to the secured area, it would display content
> properly. As a test, I logged out, closed my browser and started again,
> this time entering an incorrect login/password - again it would not forward
> to the next screen properly, however this time when I typed in the full URL,
> it would not display as the session hadn't been created.
>
> I've spoken briefly with my clients IT person, however he's unwilling to
> share any firewall information or really anything regarding their security
> setup - which I understand as I'm not an employee and just a contractor.
>
> So, after long winded description - does anyone with network security
> experience have any idea either a) what I would need to ask the IT person to
> allow for their site only, or b) have any suggestions for alternate password
> authentication that may work given the above conditions?
>
> TIA
> -Tim
>
You could check your access logs when that client is logging in to see
exactly what the browser is requesting. That might give you a hint as
to what is going on. Also you might check the error log for any fatal
errors if you're just getting a white screen. Perhaps this IE
configuration is somehow triggering a piece of code that no others
have been able to before.
Are you using header redirects? Perhaps you might change your logic
to be something like:
header("Location: ...");
<a href="...">Click here to go since your browser ignored the header</a>
Just some thoughts, good luck!
attached mail follows:
---- Tim Thorburn <immortal
nwconx.net> wrote:
> Hi all,
>
> Having a slight problem with a demo I gave at a clients last week -
> looking for a little advise. Part of my demo involved a password
> protected area - the simplified process is: client enters password on
> login page > if login/password match encrypted database, PHP session is
> created, form forwards to a secured area > secured area checks to make
> sure PHP session is valid > if valid display content, if not, return to
> login screen.
>
> This procedure is what I've used for many years, tested on a variety of
> servers and connections. It works. During the demo with my client, I
> was able to enter login/password info, the PHP session was created -
> however the screen would not forward to the secured area. Instead I was
> pretended with a blank screen (client only has an outdated/non-updated
> version of IE6). If I were to type in the URL to the secured area, it
> would display content properly. As a test, I logged out, closed my
> browser and started again, this time entering an incorrect
> login/password - again it would not forward to the next screen properly,
> however this time when I typed in the full URL, it would not display as
> the session hadn't been created.
>
> I've spoken briefly with my clients IT person, however he's unwilling to
> share any firewall information or really anything regarding their
> security setup - which I understand as I'm not an employee and just a
> contractor.
>
> So, after long winded description - does anyone with network security
> experience have any idea either a) what I would need to ask the IT
> person to allow for their site only, or b) have any suggestions for
> alternate password authentication that may work given the above conditions?
>
> TIA
> -Tim
It sounds like your code is hokey, since IE is more stringent then other browsers, the code looks to be at fault.
What browsers did you test this with before taking it to the client?
Firewalls shouldn't be any type of issue at all in this case, unless your browser is trying to redirect to another port, in which case, that should be something that the firewall won't affect internally anyways.
So all roads point back to code failure.
Wolf
attached mail follows:
[snip]
>
> It sounds like your code is hokey, since IE is more stringent then other
> browsers, the code looks to be at fault.
>
> What browsers did you test this with before taking it to the client?
>
> Firewalls shouldn't be any type of issue at all in this case, unless your
> browser is trying to redirect to another port, in which case, that should be
> something that the firewall won't affect internally anyways.
>
> So all roads point back to code failure.
>
> Wolf
>
> [/snip]
Windows more stringent?? bahahahahhahaha
But it does sound like a code failure, with error reporting turned off.
While this is appropriate for a production machine, it can play havoc with
the debugging if something is not set quite right.
--
Bastien
Cat, the other other white meat
attached mail follows:
At 8:44 AM -0400 5/19/08, Wolf wrote:
>It sounds like your code is hokey, since IE is more stringent then
>other browsers, the code looks to be at fault.
The term "stringent" isn't what comes to mind when I think about IE's.
Tim:
Did other browsers work?
Cheers,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
attached mail follows:
Wolf wrote:
> ... since IE is more stringent then other browsers ...
You are either using a very unusual IE or you are on another planet.
/Per Jessen, Zürich
attached mail follows:
> ---- Tim Thorburn <immortal
nwconx.net> wrote:
>> Hi all,
>>
>> Having a slight problem with a demo I gave at a clients last week -
>> looking for a little advise. Part of my demo involved a password
>> protected area - the simplified process is: client enters password on
>> login page > if login/password match encrypted database, PHP session
>> is created, form forwards to a secured area > secured area checks to
>> make sure PHP session is valid > if valid display content, if not,
>> return to login screen.
>>
>> This procedure is what I've used for many years, tested on a variety
>> of
>> servers and connections. It works. During the demo with my client,
>> I was able to enter login/password info, the PHP session was created
>> - however the screen would not forward to the secured area.
What kind of "forwarding" are you using? An http redirect should work
fine, regardless of which browser you're using. When you
say "secured", do you mean an https connection? If not, you're using
port 80 only which should not give you any problems.
>> So, after long winded description - does anyone with network security
>> experience have any idea either a) what I would need to ask the IT
>> person to allow for their site only, or b) have any suggestions for
>> alternate password authentication that may work given the above
>> conditions?
Maybe check if they'e using any web content filtering?
/Per Jessen, Zürich
attached mail follows:
On May 18, 2008, at 10:14 PM, Tim Thorburn wrote:
> Hi all,
>
> Having a slight problem with a demo I gave at a clients last week -
> looking for a little advise. Part of my demo involved a password
> protected area - the simplified process is: client enters password
> on login page > if login/password match encrypted database, PHP
> session is created, form forwards to a secured area > secured area
> checks to make sure PHP session is valid > if valid display content,
> if not, return to login screen.
>
> This procedure is what I've used for many years, tested on a variety
> of servers and connections. It works. During the demo with my
> client, I was able to enter login/password info, the PHP session was
> created - however the screen would not forward to the secured area.
> Instead I was pretended with a blank screen (client only has an
> outdated/non-updated version of IE6). If I were to type in the URL
> to the secured area, it would display content properly. As a test,
> I logged out, closed my browser and started again, this time
> entering an incorrect login/password - again it would not forward to
> the next screen properly, however this time when I typed in the full
> URL, it would not display as the session hadn't been created.
>
> I've spoken briefly with my clients IT person, however he's
> unwilling to share any firewall information or really anything
> regarding their security setup - which I understand as I'm not an
> employee and just a contractor.
>
> So, after long winded description - does anyone with network
> security experience have any idea either a) what I would need to ask
> the IT person to allow for their site only, or b) have any
> suggestions for alternate password authentication that may work
> given the above conditions?
>
> TIA
> -Tim
try to use a full url instead of relative. e.g.
header('location: thankyou.php');
vs.
header('location: http://www.mysite.com/thankyou.php');
or use $_SERVER['DOCUMENT_ROOT'] for portability.
i think this is some weirdness on IE6. this worked for me.
attached mail follows:
robert wrote:
> try to use a full url instead of relative. e.g.
>
> header('location: thankyou.php');
>
> vs.
>
> header('location: http://www.mysite.com/thankyou.php');
You should _always_ use an absolute URL in a redirect. I know it quite
often works with a relative too.
/Per Jessen, Zürich
attached mail follows:
> You should _always_ use an absolute URL in a redirect. I know it quite
> often works with a relative too.
Why?
--
Richard Heyes
Employ me
http://www.phpguru.org/cv
+----------------------------------------+
| Access SSH with a Windows mapped drive |
| http://www.phpguru.org/sftpdrive |
+----------------------------------------+
attached mail follows:
On Mon, May 19, 2008 at 12:52 PM, Richard Heyes <richardh
phpguru.org> wrote:
>> You should _always_ use an absolute URL in a redirect. I know it quite
>> often works with a relative too.
>
> Why?
>
> --
> Richard Heyes
>
> Employ me
> http://www.phpguru.org/cv
>
> +----------------------------------------+
> | Access SSH with a Windows mapped drive |
> | http://www.phpguru.org/sftpdrive |
> +----------------------------------------+
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Because it is RFC.
attached mail follows:
---- Per Jessen <per
computer.org> wrote:
> Wolf wrote:
>
> > ... since IE is more stringent then other browsers ...
>
> You are either using a very unusual IE or you are on another planet.
>
Nope IE and Opera both wait for full page before displaying (while firefox displays as output) and IE has always been more stringent in-so-far as displaying things that match up to THEIR standards instead of industry or fly-by-your-seat coding (accidentally leaving off a closing tag) then Mozilla and Firefox have historically been.
Hence more stringent...
Though really MicroShaft thinks everyone should be coding to THEIR standards and not the world.
*shrug*
attached mail follows:
Kaja wrote:
> Does anyone know if any of the PHP 5 XML libraries use flock() internally?
> I'd like to use XMLReader and XMLWriter but I need to make sure theres no
> writing going on while reading and no more than one writer at time. And if
> I have to use DOM, does DOM lock the file when it calls save()?
>
> Or is there any xml library that allows you to pass in an already opened
> file stream ?
>
> Thanks.
For such a low level question, I think you better ask on the developers
list.
Iv
attached mail follows:
Regarding the XML/flock file locking question...
Couldn't you also create a rather simple test to determine if the locking of the file takes place??
-----Original Message-----
From: Iv Ray [mailto:pobox
verysmall.org]
Sent: Monday, May 19, 2008 6:38 AM
To: Kaja
Cc: php-general
lists.php.net
Subject: Re: [PHP] XML file locking
Kaja wrote:
> Does anyone know if any of the PHP 5 XML libraries use flock() internally?
> I'd like to use XMLReader and XMLWriter but I need to make sure theres no
> writing going on while reading and no more than one writer at time. And if
> I have to use DOM, does DOM lock the file when it calls save()?
>
> Or is there any xml library that allows you to pass in an already opened
> file stream ?
>
> Thanks.
For such a low level question, I think you better ask on the developers
list.
Iv
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
attached mail follows:
bruce wrote:
> Couldn't you also create a rather simple test to determine if the locking of the file takes place?
I personally do not trust file system level locks. Even if a software is
not intended to be portable across operating systems, it is possible to
use different file systems under the same operating system, and the
rules might be different. Using file system level locks would require
all possible file systems to be taken into account. And on top of that,
the file systems are actively developed, so this is one more point to
monitor, while maintaining the software. A less trouble free way is to
create a file with the same name and extension ".locked" or similar,
prior to read/write operations. Of course, this works only if the file
is accessing only by one program, or if all programs accessing the file
follow the same convention - but you should see that many file system
level locks are advisory, as well.
See this -
http://en.wikipedia.org/wiki/File_locking
--
attached mail follows:
i seriously 2nd what Ivy has stated...
i recently had a short situation where i was dealing with an nfs shared folder, and had to roll my own "locking" process...
also, keep in mind that if you have multiple processes accessing the targeted file, then you really need to test various situations to get a feel for how often you might run into file conflicts...
-----Original Message-----
From: Iv Ray [mailto:pobox
verysmall.org]
Sent: Monday, May 19, 2008 7:45 AM
To: bruce
Cc: 'Kaja'; php-general
lists.php.net
Subject: Re: [PHP] XML file locking
bruce wrote:
> Couldn't you also create a rather simple test to determine if the locking of the file takes place?
I personally do not trust file system level locks. Even if a software is
not intended to be portable across operating systems, it is possible to
use different file systems under the same operating system, and the
rules might be different. Using file system level locks would require
all possible file systems to be taken into account. And on top of that,
the file systems are actively developed, so this is one more point to
monitor, while maintaining the software. A less trouble free way is to
create a file with the same name and extension ".locked" or similar,
prior to read/write operations. Of course, this works only if the file
is accessing only by one program, or if all programs accessing the file
follow the same convention - but you should see that many file system
level locks are advisory, as well.
See this -
http://en.wikipedia.org/wiki/File_locking
--
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
attached mail follows:
Hello list,
Is there anyone having experience with finding "dead code" in their
library / application?
Dead code as in unused variables, uncalled methods, uncalled functions,
undeclared classes etc.
Any help on examples, resources etc. is much appreciated.
--
Aschwin Wesselius
/'What you would like to be done to you, do that to the other....'/
attached mail follows:
On Mon, May 19, 2008 at 11:06 AM, Aschwin Wesselius
<aschwin
illuminated.nl> wrote:
> Hello list,
>
> Is there anyone having experience with finding "dead code" in their library
> / application?
>
> Dead code as in unused variables, uncalled methods, uncalled functions,
> undeclared classes etc.
>
> Any help on examples, resources etc. is much appreciated.
> --
>
> Aschwin Wesselius
>
> /'What you would like to be done to you, do that to the other....'/
>
Maybe this will help http://xdebug.org/docs/code_coverage
attached mail follows:
Hello,
The option PGSQL_DML_STRING doesn't work with pg_update to me. I try the
same option with pg_insert and it worked as I expected, but with
pg_update I can't see the query and it is executed.
I have an error in the query and I need to debug, so watch it is imperative.
Anybody can help me to know what I need to do to be able to debug the query?
Thanks in advance.
CODE AND RESULT AT THE BROWSER:
function Update_internal($taula, $elements, $id, $dieonerror=true, $format_date=true) {
$link = Conectar();
pg_query($link, 'SET DateStyle TO ISO');
foreach (array_keys($elements) as $k) {
$elements[$k]=stripslashes($elements[$k]);
if ($format_date && $elements[$k]) {
if (preg_match('/^(\d{1,2})[-\/\.](\d{1,2})[-\/\.](\d{4})$/', $elements[$k], $match))
$elements[$k]=$match[3].'/'.$match[2].'/'.$match[1];
}
}
$aux = "Update Internal en $taula\n" . print_r($elements,true) . "\nfor ID=$id\n";
file_put_contents('/tmp/pedidos.log',$aux,FILE_APPEND);
$res = pg_update($link, $taula, $elements, Array('id' => $id),PGSQL_DML_STRING);
$aux = "QUERY: " . $res . "\n";
file_put_contents('/tmp/pedidos.log',$aux,FILE_APPEND);
if ($res) return true;
if ($dieonerror) dieEx("Error al actualizar los datos en $taula",'Mensaje devuelto por el servidor: '.pg_errormessage ($link));
return false;
}
The only error I can see is at the browser, but any information is shown:
ERROR
Se ha producido un error al ejecutar el script Número de error: 0
Descripción:
Error al actualizar los datos en comandes
Mensaje devuelto por el servidor:
--
attached mail follows:
So have developed some nice tools for generating forms,
connecting to databases, things that I do repeatedly.
When I run test pages that include these utility files
in the same directory as the utility files it works
fine. The are included no problem. As soon as I have
scripts in other directories include these utility
tools it breaks.
Here is my path structure
Page that uses the tools:
/srv/www/html/lib/index.html
Tools:
/srv/www/html/Tools/formtool/formtool.php
/srv/www/html/Tools/dbtool/dbtool.php
/srv/www/html/secdepot/libquery.inc
phpinfo() returns:
doc_root /srv/www/html /srv/www/html
include_path .:/srv/www/html .:/srv/www/html
in the index.html I have tried:
ini_set( 'include_path',
'/srv/www/html/Tools:/srv/www/html/secdepot:.');
require 'dbtools/dbtool.php';
require 'libquery.inc';
require 'formtool/formclasses.php';
errors:
require(dbtools/dbtool.php) [function.require]:
failed to open stream: No such file or directory
/srv/www/html/lib/index.php, line 12
require() [function.require]: Failed opening required
'dbtools/dbtool.php'
(include_path='/srv/www/html/Tools:/srv/www/html/secdepot:.')
/srv/www/html/lib/index.php, line 12
as well as:
require '/srv/www/html/Tools/dbtools/dbtool.php';
require '/srv/www/html/secdepot/libquery.inc';
require '/srv/www/html/Tools/formtool/formclasses.php';
error:
require(/srv/www/html/Tools/dbtools/dbtool.php)
[function.require]: failed to open stream: No such file
or directory /srv/www/html/lib/index.php, line 11
require() [function.require]: Failed opening required
'/srv/www/html/Tools/dbtools/dbtool.php'
(include_path='.:/srv/www/html')
/srv/www/html/lib/index.php, line 11
as well as:
require 'dbtools/dbtool.php';
require 'libquery.inc';
require 'formtool/formclasses.php';
error:
require(Tools/dbtools/dbtool.php) [function.require]:
failed to open stream: No such file or directory
/srv/www/html/lib/index.php, line 11
require() [function.require]: Failed opening required
'Tools/dbtools/dbtool.php'
(include_path='.:/srv/www/html')
/srv/www/html/lib/index.php, line 11
as far as I can tell I am not chrooted:
?>ps aux | grep httpd
outputs:
root 1937 0.0 5.2 25600 13456 ? Ss 19:50
0:00 /usr/sbin/httpd
raa-web 1956 0.3 0.8 4636 2084 ? S 19:50
0:14 /usr/sbin/lighttpd -f /etc/raa/lighttpd.conf
apache 1987 0.0 4.2 25736 10920 ? S 19:50
0:00 /usr/sbin/httpd
apache 1990 0.0 4.2 25736 10892 ? S 19:50
0:00 /usr/sbin/httpd
apache 1993 0.0 4.3 25736 11048 ? S 19:50
0:00 /usr/sbin/httpd
apache 1995 0.0 4.2 25736 10908 ? S 19:50
0:00 /usr/sbin/httpd
apache 2003 0.0 4.2 25736 10912 ? S 19:50
0:00 /usr/sbin/httpd
apache 2008 0.0 4.2 25736 10908 ? S 19:50
0:00 /usr/sbin/httpd
apache 2011 0.0 4.2 25736 10864 ? S 19:50
0:00 /usr/sbin/httpd
apache 2014 0.0 4.2 25736 10900 ? S 19:50
0:00 /usr/sbin/httpd
root 2644 0.0 0.3 2908 788 tty1 R+ 20:57
0:00 grep httpd
Am I missing something blatently obvious?
attached mail follows:
Tyson Vanover wrote:
>
> Am I missing something blatently obvious?
>
Maybe open_basedir or safe_mode restrictions?
--
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
attached mail follows:
Nevermind, working.
attached mail follows:
i just saw this last message and forgive me if I'm missing something
but why not use $_SERVER['DOCUMENT_ROOT'] as a prefix to any of the
paths?
On May 19, 2008, at 10:49 AM, Tyson Vanover wrote:
> So have developed some nice tools for generating forms, connecting
> to databases, things that I do repeatedly. When I run test pages
> that include these utility files in the same directory as the
> utility files it works fine. The are included no problem. As soon
> as I have scripts in other directories include these utility tools
> it breaks.
>
> Here is my path structure
> Page that uses the tools:
> /srv/www/html/lib/index.html
>
> Tools:
> /srv/www/html/Tools/formtool/formtool.php
> /srv/www/html/Tools/dbtool/dbtool.php
> /srv/www/html/secdepot/libquery.inc
>
> phpinfo() returns:
> doc_root /srv/www/html /srv/www/html
> include_path .:/srv/www/html .:/srv/www/html
>
> in the index.html I have tried:
> ini_set( 'include_path', '/srv/www/html/Tools:/srv/www/html/
> secdepot:.');
> require 'dbtools/dbtool.php';
> require 'libquery.inc';
> require 'formtool/formclasses.php';
> errors:
> require(dbtools/dbtool.php) [function.require]: failed to open
> stream: No such file or directory /srv/www/html/lib/index.php, line 12
> require() [function.require]: Failed opening required 'dbtools/
> dbtool.php' (include_path='/srv/www/html/Tools:/srv/www/html/
> secdepot:.') /srv/www/html/lib/index.php, line 12
>
> as well as:
> require '/srv/www/html/Tools/dbtools/dbtool.php';
> require '/srv/www/html/secdepot/libquery.inc';
> require '/srv/www/html/Tools/formtool/formclasses.php';
> error:
> require(/srv/www/html/Tools/dbtools/dbtool.php) [function.require]:
> failed to open stream: No such file or directory /srv/www/html/lib/
> index.php, line 11
> require() [function.require]: Failed opening required '/srv/www/html/
> Tools/dbtools/dbtool.php' (include_path='.:/srv/www/html') /srv/www/
> html/lib/index.php, line 11
>
> as well as:
> require 'dbtools/dbtool.php';
> require 'libquery.inc';
> require 'formtool/formclasses.php';
> error:
> require(Tools/dbtools/dbtool.php) [function.require]: failed to open
> stream: No such file or directory /srv/www/html/lib/index.php, line 11
> require() [function.require]: Failed opening required 'Tools/dbtools/
> dbtool.php' (include_path='.:/srv/www/html') /srv/www/html/lib/
> index.php, line 11
>
> as far as I can tell I am not chrooted:
> ?>ps aux | grep httpd
> outputs:
> root 1937 0.0 5.2 25600 13456 ? Ss 19:50 0:00 /usr/
> sbin/httpd
> raa-web 1956 0.3 0.8 4636 2084 ? S 19:50 0:14 /usr/
> sbin/lighttpd -f /etc/raa/lighttpd.conf
> apache 1987 0.0 4.2 25736 10920 ? S 19:50 0:00 /usr/
> sbin/httpd
> apache 1990 0.0 4.2 25736 10892 ? S 19:50 0:00 /usr/
> sbin/httpd
> apache 1993 0.0 4.3 25736 11048 ? S 19:50 0:00 /usr/
> sbin/httpd
> apache 1995 0.0 4.2 25736 10908 ? S 19:50 0:00 /usr/
> sbin/httpd
> apache 2003 0.0 4.2 25736 10912 ? S 19:50 0:00 /usr/
> sbin/httpd
> apache 2008 0.0 4.2 25736 10908 ? S 19:50 0:00 /usr/
> sbin/httpd
> apache 2011 0.0 4.2 25736 10864 ? S 19:50 0:00 /usr/
> sbin/httpd
> apache 2014 0.0 4.2 25736 10900 ? S 19:50 0:00 /usr/
> sbin/httpd
> root 2644 0.0 0.3 2908 788 tty1 R+ 20:57 0:00 grep
> httpd
>
> Am I missing something blatently obvious?
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
attached mail follows:
nevermind. It is working now. Thanks all!
attached mail follows:
http://pecl.php.net/get/threads
File not found
;P
Atenciosamente,
www.softpartech.com.br
Thiago Henrique Pojda
Desenvolvimento Web
+55 41 3033-7676
thiago.pojda
softpartech.com.br
Excelência em Softwares Financeiros
-----Mensagem original-----
De: Per Jessen [mailto:per
computer.org]
Enviada em: sábado, 17 de maio de 2008 11:13
Para: php-general
lists.php.net
Assunto: Re: [PHP] Threads PHP
Richard Heyes wrote:
>
> > Summary: experimental implementation of threads
>
> The word "experimental" makes me shudder.
"PHP" and "threads" in the same sentence make me shudder too. There are
just some things you shouldn't do with an interpreted language IMHO.
/Per Jessen, Zürich
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]