simpletest-support — Help, advice, bugs and workarounds.

Re: [Simpletest-support] Web form submitting

[Claude P. <cl...@2x...>]

Le vendredi 26 septembre 2008 à 19:41 +0100, Marcus Baker a écrit :
> Hi...
> 
> Claude Paroz wrote:
> > I don't know. I have very few control on the host environment. Is
> > SimpleTest able to send HTTP 1.1 requests?
> 
> You might be able to configure it in the browser.
> 
> In the meantime try using addHeader() in SimpleTest to replicate the 
> request exactly, especially referrer and accept headers.

Thanks, that did the trick! The "Referer" header was mandatory (at least
for this server). Adding a this->addHeader('Referer: <page.html>');
solved my problem.
It might by something to add by default in all submit requests in
SimpleTest.

Many thanks for the support.

Claude

Re: [Simpletest-support] Web form submitting

[Marcus B. <ma...@wo...>]

Hi...

Claude Paroz wrote:
> I don't know. I have very few control on the host environment. Is
> SimpleTest able to send HTTP 1.1 requests?

You might be able to configure it in the browser.

In the meantime try using addHeader() in SimpleTest to replicate the 
request exactly, especially referrer and accept headers.

> 
> Claude

yours, Marcus

Re: [Simpletest-support] [Simpletest-devel] Expired cookies being sent with requests

[Travis S. <dev...@do...>]

Hey Taras;

Most of the development talk goes on on the simpletest-support mailing  
list.  I've CC'd that list on this response, so everyone over there  
can see this as well.

-T


On Sep 26, 2008, at 4:50 AM, Taras Diakiw wrote:

> In case anyone else was reading this, my suggestion would not work,  
> because isExpired returns true if the cookie is a session cookie  
> (although it hasn't expired until the browser closes - go figure).  
> So instead...
>
> Add the following method to SimpleCookie class:
>
>    function isExpiredSession($now)
>    {
>        if (! $this->_expiry) {
>            return false;
>        }
>        if (is_string($now)) {
>            $now = strtotime($now);
>        }
>        return ($this->_expiry < $now);
>    }
>
> change the SimpleCookieJar::selectAsPairs function to:
>
>    /**
>     *    Uses a URL to sift relevant cookies by host and
>     *    path. Results are list of strings of form "name=value".
>     *    @param SimpleUrl $url       Url to select by.
>     *    @return array               Valid name and value pairs.
>     *    @access public
>     */
>    function selectAsPairs($url) {
>        $pairs = array();
>        foreach ($this->_cookies as $cookie) {
>            if ($this->_isMatch($cookie, $url->getHost(), $url- 
> >getPath(), $cookie->getName())) {
>            	// taras
> 				if(!$cookie->isExpiredSession(time())) {
> 					$pairs[] = $cookie->getName() . '=' . $cookie->getValue();
> 				}
>            }
>        }
>        return $pairs;
>    }
>
>> -----Original Message-----
>> From: sim...@li...
>> [mailto:sim...@li...]On Behalf Of
>> Taras Diakiw
>> Sent: 04 September 2008 17:59
>> To: sim...@li...
>> Subject: [Simpletest-devel] Expired cookies being sent with requests
>>
>>
>> Hi all developers!
>>
>> I'm new to this open source development, so apologies if I
>> break some established conventions.
>>
>> I've been trying to figure out how to delete cookies. As far
>> as I know, browsers do not send cookies that have expired
>> with requests, so you should be able to set the expiry date
>> of a cookie you wish to get rid of to a time in the past. At
>> the moment, SimpleTest will send cookies in the cookie jar
>> regardless of their expiry date.
>>
>> The fix is simple enough, but I would like to confirm that my
>> interpretation is inline with actual browser behaviour
>> (before I go ahead making changes to the code). That is,
>> should the browser behaviour be changed so that it doesn't
>> send cookies that have expired?
>>
>> The fix is simple enough, just ensure that
>> SimpleCookieJar::selectAsPairs considers the expiry date:
>>
>>   if ($this->_isMatch($cookie, $url->getHost(),
>> $url->getPath(), $cookie->getName())) {
>>                if(!$cookie->isExpired(time())) {
>> 					$pairs[] =
>> $cookie->getName() . '=' . $cookie->getValue();
>> 				}
>>            }
>>
>> The selectAsPairs function is only ever called in one place,
>> where the HTTP request gets constructed.
>>
>> Cheers,
>>
>> Taras Diakiw
>> Software Developer
>> Practical Law Company
>> T: +44 (0) 20 7202 1200 ext 5629
>> F: +44 (0) 20 7202 1211
>> W: http://www.practicallaw.com
>>
>>
>> Practical Law Company Limited. Registered in England and
>> Wales. Registered Number: 02889191. Registered Office: 19
>> Hatfields, London SE1 8DJ. Telephone: +44(0)20 7202 1200.
> http://www.practicallaw.com. DISCLAIMERS: This e-mail is  
> confidential to the ordinary user of the e-mail address to which it  
> was addressed; it may contain personal views which are not the views  
> of PLC unless specifically stated.  If you have received it in  
> error, please delete it from your system and notify the sender  
> immediately; do not use, copy or disclose the information or  
> otherwise use it or any part of it in any form whatsoever nor act in  
> reliance on it.  All liability for loss or damage caused by viruses  
> is excluded.  PLC uses the MessageLabs SkyScan service to monitor  
> all outgoing and incoming e-mails for viruses, prohibited file-type  
> attachments and inappropriate content in accordance with its  
> Information and Communications Systems policy.  You signify your  
> consent to these terms by any further e
> -mail communication.
>
> Save a tree...please don't print this e-mail unless you really need  
> to.
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win  
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in  
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Simpletest-devel mailing list
> Sim...@li...
> https://lists.sourceforge.net/lists/listinfo/simpletest-devel
>
> This e-mail from Practical Law Company (http://www.practicallaw.com)  
> is subject to our terms of use (http://www.practicallaw.com/ 
> 9-103-0884). Information about our companies: Practical Law Company  
> Limited. Registered in England and Wales. Registered Number:  
> 02889191. Registered Office: 19 Hatfields, London SE1 8DJ.  
> Telephone: +44(0)20 7202 1200.  Practical Law Company, Inc.  
> Incorporated in Delaware, USA.  Corporate Office: 747 Third Avenue,  
> 36th Floor, New York, NY 10017. Telephone: +1(646) 562-3400.
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win  
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in  
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Simpletest-devel mailing list
> Sim...@li...
> https://lists.sourceforge.net/lists/listinfo/simpletest-devel

Re: [Simpletest-support] Web form submitting

[Claude P. <cl...@2x...>]

Le vendredi 26 septembre 2008 à 17:03 +0100, Marcus Baker a écrit :
> Hi...
> 
> Claude Paroz wrote:
> > class testDemandes extends WebTestCase {
> 
> I get this page...
> 
> --------
> <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
> <HTML><HEAD>
> <TITLE>403 Forbidden</TITLE>
> </HEAD><BODY>
> <H1>Forbidden</H1>
> You don't have permission to access /bibles/demande.php
> on this server.<P>
> </BODY></HTML>
> --------

Yes, that's also what I'm getting.

> That is, your own page is saying it's a request to 
> "/bibles/demande.php", so it's not a URL parsing problem.
> 
> Here is the request:
> 
> --------
> POST /bibles/demande.php HTTP/1.0
> Host: www.bibles.ch
> Connection: close
> Content-Length: 194
> Content-Type: application/x-www-form-urlencoded
> 
> bibleform=suisse&Reactions=Test+demande&Bible=OUI&Prenom=Test+pr%C3%A9nom&Nom=Test+nom&Adresse=Test+adresse&Codepostal=Test+CP&Ville=Test+ville&Pays=Suisse&email=test%40email.com&Envoyer=Envoyer
> --------
> 
> Is this post request correct? What do you get if you use wireshark 
> with a successful browser request?

Here is a valid request captured through Firefox Live HTTP headers :

POST /bibles/demande.php HTTP/1.1
Host: www.bibles.ch
User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.0.3)
Gecko/2008092510 Ubuntu/8.04 (hardy) Firefox/3.0.3 Ubuntu
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: fr-ch,fr-fr;q=0.8,en-us;q=0.6,en;q=0.4,de-ch;q=0.2
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://www.bibles.ch/bibles/52_suisse.htm
Content-Type: application/x-www-form-urlencoded
Content-Length: 154
bibleform=suisse&Reactions=Test&Bible=OUI&Prenom=Claude&Nom=Paroz&Adresse=test&Codepostal=1234&Ville=Test&Pays=Suisse&email=test%40test.ch&Envoyer=Envoyer


>  Does your host accept HTTP 1.0 
> requests for example?

I don't know. I have very few control on the host environment. Is
SimpleTest able to send HTTP 1.1 requests?

Claude

Re: [Simpletest-support] Web form submitting

[Marcus B. <ma...@wo...>]

Hi...

Claude Paroz wrote:
> class testDemandes extends WebTestCase {

I get this page...

--------
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>403 Forbidden</TITLE>
</HEAD><BODY>
<H1>Forbidden</H1>
You don't have permission to access /bibles/demande.php
on this server.<P>
</BODY></HTML>
--------

That is, your own page is saying it's a request to 
"/bibles/demande.php", so it's not a URL parsing problem.

Here is the request:

--------
POST /bibles/demande.php HTTP/1.0
Host: www.bibles.ch
Connection: close
Content-Length: 194
Content-Type: application/x-www-form-urlencoded

bibleform=suisse&Reactions=Test+demande&Bible=OUI&Prenom=Test+pr%C3%A9nom&Nom=Test+nom&Adresse=Test+adresse&Codepostal=Test+CP&Ville=Test+ville&Pays=Suisse&email=test%40email.com&Envoyer=Envoyer
--------

Is this post request correct? What do you get if you use wireshark 
with a successful browser request? Does your host accept HTTP 1.0 
requests for example?

> 
> Claude

yours, Marcus

Re: [Simpletest-support] Web form submitting

[Claude P. <cl...@2x...>]

Le mercredi 24 septembre 2008 à 11:33 +0100, Marcus Baker a écrit :
> Hi...
> 
> Claude Paroz wrote:
> > I'm suspecting the problem is with the interpretation of the root (/) on
> > the server. Is it possible to tell SimpleTest to prefix all URLs with
> > the absolute path, including the domain name?
> 
> It should already be doing this. Can you post the full test method?

class testDemandes extends WebTestCase {
    
    function setUp() {
        $this->get('http://www.bibles.ch/bibles/52_suisse.htm');
    }
    
    function testDemandeSuisse() {
        $this->assertPattern('/Notre association offre gratuitement une
Bible/');
        # Fill in form
        $this->setField('Reactions', 'Test demande');
        $this->setField('Prenom', 'Test prénom');
        $this->setField('Nom', 'Test nom');
        $this->setField('Adresse', 'Test adresse');
        $this->setField('Codepostal', 'Test CP');
        $this->setField('Ville', 'Test ville');
        $this->setField('email', 'te...@em...');
        $this->clickSubmit('Envoyer');
        /* Debugging purpose */
        /*$this->showRequest();
        $this->showHeaders(); */
        $this->assertPattern('/Votre demande a bien été enregistrée,
merci/');
    }
    
    function testDemandeSansFormulaire() {
        $this->get('http://www.bibles.ch/bibles/demande.php');
        $this->assertPattern('/Erreur: pas de données de formulaire/');
    }
}

> 
> Of course you could also set the base URL in the page, but that 
> would involve modifying the page to get the test to work - which is 
> a no-no :(.

I already tried to set an absolute URL in the action form property, with
no luck.

Claude

Re: [Simpletest-support] Web form submitting

[Marcus B. <ma...@wo...>]

Hi...

Claude Paroz wrote:
> I'm suspecting the problem is with the interpretation of the root (/) on
> the server. Is it possible to tell SimpleTest to prefix all URLs with
> the absolute path, including the domain name?

It should already be doing this. Can you post the full test method?

Of course you could also set the base URL in the page, but that 
would involve modifying the page to get the test to work - which is 
a no-no :(.

> 
> Claude

yours, Marcus

[Simpletest-support] Web form submitting

[Claude P. <cl...@2x...>]

Hi,

I'm probably missing something very obvious, but I can't figure it out.
I'm testing a Web form with SimpleTest (the form currently works well on
the Web), and when I do a $this->clickSubmit('Envoyer');, I'm getting a
"403 Forbidden" error (You don't have permission to
access /folder/file.php on this server).

That's strange, because if I do a simple get() with the same destination
as the form action URL, I'm getting the page (with an error in the page
content because there is no form data, of course).

I'm suspecting the problem is with the interpretation of the root (/) on
the server. Is it possible to tell SimpleTest to prefix all URLs with
the absolute path, including the domain name?

Claude

Re: [Simpletest-support] More @var phpdoc tags for private variables

[Mark R. <ma...@co...>]

I don't mind the @var tags for public properties, but my personal
opinion is that it is a bad smell to add code specifically to give
hints to an IDE. I know that static analysis of PHP code structure is
more difficult than say, Java, and while sprinkling the code with
comments would make this static analysis easier, there are also
negative effects such as expansion of vertical space and the extra
effort needed to keep the comments up to date.

Re: [Simpletest-support] More @var phpdoc tags for private variables

[Elijah I. <tm...@gm...>]

as a personal preference I like to see all of my code consistently commented
as it makes the most logical sense in my opinion to add all of the
comments.  For a few reasons:

1. Granting would be developers/patch submitters less of a steep slope to
get up to speed

2. The possibility of the project being abandoned and another developer
taking over.

3. If you use phpDocumentor it is quite simple to grasp what certain code is
used for and how to use it (assuming comments are correctly and fully added)

Comments are good! My 2 cents :)
--Elijah

On Fri, Sep 12, 2008 at 8:47 AM, Travis Swicegood
<dev...@do...>wrote:

> On Sep 11, 2008, at 2:31 PM, Perrick Penet wrote:
>
> > Chris asked on the bugs tracker for @var phpdoc tags. On the
> > devel-mailing list, Travis answered we were not going to implement
> > this
> > feature for a bunch of entirely good reasons (see his answer below).
> >
> > However whenever I'm in the middle of a debugging session -- again a
> > few
> > minutes ago trying to correct a problem with assertNoCookies -- I
> > found
> > these Eclipse shortcuts really useful when navigating to the root
> > cause.
> > So I'd be tempted to add them anyway. What do you think ?
>
> Adding my voice to the -1 camp.  I think they add more work than
> they're worth.  Plus, if you're working on them, shouldn't they be
> obviously named so a docblock isn't needed?  Superfluous inline docs
> normally are a sign that something needs to be refactored to be more
> obvious.
>
> Of course, take that with a grain of salt.  I stay far away from the
> WebTester stuff ;-)
>
> -T
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Simpletest-support mailing list
> Sim...@li...
> https://lists.sourceforge.net/lists/listinfo/simpletest-support
>

Re: [Simpletest-support] More @var phpdoc tags for private variables

[Travis S. <dev...@do...>]

On Sep 11, 2008, at 2:31 PM, Perrick Penet wrote:

> Chris asked on the bugs tracker for @var phpdoc tags. On the
> devel-mailing list, Travis answered we were not going to implement  
> this
> feature for a bunch of entirely good reasons (see his answer below).
>
> However whenever I'm in the middle of a debugging session -- again a  
> few
> minutes ago trying to correct a problem with assertNoCookies -- I  
> found
> these Eclipse shortcuts really useful when navigating to the root  
> cause.
> So I'd be tempted to add them anyway. What do you think ?

Adding my voice to the -1 camp.  I think they add more work than  
they're worth.  Plus, if you're working on them, shouldn't they be  
obviously named so a docblock isn't needed?  Superfluous inline docs  
normally are a sign that something needs to be refactored to be more  
obvious.

Of course, take that with a grain of salt.  I stay far away from the  
WebTester stuff ;-)

-T

Re: [Simpletest-support] More @var phpdoc tags for private variables

[Marcus B. <ma...@wo...>]

Hi...

Perrick Penet wrote:
> What do you think ?

Well, coding standards should be democratic among the core team. IN 
that spirit I "vote" no. I think they have very poor ROI given the 
amount of clutter and vertical space they use up.

> 
> Yours,
> 	Perrick

yours, Marcus

Re: [Simpletest-support] More @var phpdoc tags for private variables

[Noel D. <ma...@mc...>]

On Thu, 11 Sep 2008 21:31:44 +0200
Perrick Penet <pe...@no...> wrote:

> Hi everyone,
> 
> Chris asked on the bugs tracker for @var phpdoc tags. On the 
> devel-mailing list, Travis answered we were not going to implement
> this feature for a bunch of entirely good reasons (see his answer
> below).

Personally I think they add a lot of clutter without saying anything
very useful. Given that documentation often lags behind the code, they
might not even be correct.

Noel

[Simpletest-support] More @var phpdoc tags for private variables

[Perrick P. <pe...@no...>]

Hi everyone,

Chris asked on the bugs tracker for @var phpdoc tags. On the 
devel-mailing list, Travis answered we were not going to implement this 
feature for a bunch of entirely good reasons (see his answer below).

However whenever I'm in the middle of a debugging session -- again a few 
minutes ago trying to correct a problem with assertNoCookies -- I found 
these Eclipse shortcuts really useful when navigating to the root cause. 
So I'd be tempted to add them anyway. What do you think ?

Yours,
	Perrick



-------- Original Request --------
https://sourceforge.net/tracker/index.php?func=detail&aid=2090232&group_id=76550&atid=547455

-------- Original Message --------
Subject: Re: [Simpletest-devel] More @var phpdoc tags for private variables
Date: Sun, 31 Aug 2008 12:52:14 -0500
From: Travis Swicegood <dev...@do...>
Reply-To: sim...@li...
To: sim...@li...
References: <122...@n2...>

Hey Chris;

On Aug 31, 2008, at 11:16 AM, Chris Vogt wrote:

> Adding a
> 	/**
> 	 * @var SimpleBrowser
> 	 */
> before
> 	var $_browser;
> in the WebTestCase class definition solves the problem.

Thanks for the email and the kind words.  I'm sure I speak for the
rest of the team when I say it really makes the work that's gone into
ST worth it when we realize how useful others find it. :-)

That said, we won't be implementing documentation on private
attributes or methods as those are not meant to be used by other
developers.  There are a few problems with documented private methods:

* It encourages use by third-party developers
* It adds to the overhead of internal refactoring (not just the code
has to change for everything to be current)

For anything that is meant to be used directly, we do try to keep the
docblock tags as up-to-date as possible, but private variables aren't
meant to be directly accessed, so we want to make you work for them if
you're going to use them :-)

-T

Re: [Simpletest-support] Deleting a cookie

[Taras D. <Tar...@pr...>]

>
> I did notice there's a new bug for assertNoCookie():
> http://sourceforge.net/tracker/index.php?func=detail&aid=20947
18&group_id=76550&atid=547455
>
>Until that bug is fixed you could still do something like:


>function testLogout() {
>  $this->get('http://test-server/logout');
>  $this->get('http://test-server/secretResource');
>  $this->assertText('You must be signed in to access this');
>}
>
>Steve

Hi Steve,

That's not quite what I need to do. I'm trying to simulate a single sign on environment where a guid cookie is shared amonst multiple web applications. In this particular example, a web app external to the one I'm trying to simulate destroys the GUID cookie.

So:

1) User logs onto my website - global guid cookie created (effectively the user is signed into all the applications)
2) Simulate logout on different web app - global guid cookie destroyed (this is the key point. Some mechanism external to my website destroys the global guid cookie)
3) User tries to continue on my website - can't because user has been logged out (because the global guid cookie was destroyed)

So I really need some way of destroying the cookie

Does this make sense?

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Simpletest-support mailing list
Sim...@li...
https://lists.sourceforge.net/lists/listinfo/simpletest-support

Practical Law Company Limited. Registered in England and Wales. Registered Number: 02889191. Registered Office: 19 Hatfields, London SE1 8DJ. Telephone: +44(0)20 7202 1200. http://www.practicallaw.com. DISCLAIMERS: This e-mail is confidential to the ordinary user of the e-mail address to which it was addressed; it may contain personal views which are not the views of PLC unless specifically stated.  If you have received it in error, please delete it from your system and notify the sender immediately; do not use, copy or disclose the information or otherwise use it or any part of it in any form whatsoever nor act in reliance on it.  All liability for loss or damage caused by viruses is excluded.  PLC uses the MessageLabs SkyScan service to monitor all outgoing and incoming e-mails for viruses, prohibited file-type attachments and inappropriate content in accordance with its Information and Communications Systems policy.  You signify your consent to these terms by any further e-mail communication.

Save a tree...please don't print this e-mail unless you really need to.

Re: [Simpletest-support] Deleting a cookie

[Clay,Stephen B <sc...@UF...>]

Taras Diakiw:
> problem is I need to remove the cookies after they have been set in the
> mocked browser (if this makes sense).

Unless I'm missing something, do you just want something like this?

// test that logout sends a header to remove the session cookie
function testLogout() {
  $this->get('http://test-server/logout');
  $this->assertNoCookie('sessid');
}

I did notice there's a new bug for assertNoCookie():
http://sourceforge.net/tracker/index.php?func=detail&aid=2094718&group_id=76550&atid=547455

Until that bug is fixed you could still do something like:

function testLogout() {
  $this->get('http://test-server/logout');
  $this->get('http://test-server/secretResource');
  $this->assertText('You must be signed in to access this');
}

Steve

Re: [Simpletest-support] Where is the dom tester?

[Perrick P. <pe...@no...>]

Hi Dagfinn,

> It's marked as "only available in CVS", so anyone who knows that 
> SimpleTest is no longer in CVS (as I do) will dismiss it as obsolete 
> information, and those who don't are certainly not likely to find the 
> DomTestCase anywhere, any way.

I did a quick fix on the documentaion, it's now marked as "only 
available in SVN" ;-) Thanks for pointing this out.

Yours,
	Perrick

Re: [Simpletest-support] Where is the dom tester?

[Mark R. <ma...@co...>]

>
> Either way, we should we create a separate extensions section in the
> docs until it's all been beta and usability tested. Mark, is taht
> what you are doing?

Yes, that's right... I was just tagging @package and @subpackage tags
as extensions, as several classes were tagged with package names which
meant they ended up floating in the main api doc section for the unit
tester itself.

Re: [Simpletest-support] Where is the dom tester?

[Dagfinn R. <da...@re...>]

Perrick Penet wrote:
> Hi,
>
>   
>> Either way, we should we create a separate extensions section in the 
>> docs until it's all been beta and usability tested. Mark, is taht 
>> what you are doing?
>>     
>
> The DomTestCase is already marked as "un-released" in the documentation 
> on the web site.
>
>   
It's marked as "only available in CVS", so anyone who knows that 
SimpleTest is no longer in CVS (as I do) will dismiss it as obsolete 
information, and those who don't are certainly not likely to find the 
DomTestCase anywhere, any way.

Re: [Simpletest-support] Deleting a cookie

[Taras D. <Tar...@pr...>]

Hi Jason,

> -----Original Message-----
> From: sim...@li...
> [mailto:sim...@li...]On Behalf Of
> Jason Sweat
> Sent: 08 September 2008 16:03
> To: Help, advice, bugs and workarounds
> Subject: Re: [Simpletest-support] Deleting a cookie
> 
> 
> ----- Original Message ----
> 
> From: Marcus Baker <ma...@wo...>
> 
> Taras Diakiw wrote:
> > How do you delete a particular cookie?
> 
> This is a thorny one, as the browsers don't necessarily do this 
> either. SimpleTest acts like a fussy (Netscape) browser. You have to 
> explicitly set a timeout.
> 
> The FF Web Developers Toolbar allows you to delete all 
> cookies for the current domain, but this behavior can be 
> easily duplicated by just starting a new SimpleBrowser with 
> no cookies to begin with.
> 
> Regards,
> Jason

The problem isn't that I need a mocked browser with no cookies, the problem is I need to remove the cookies after they have been set in the mocked browser (if this makes sense).

So I need:

 * make new mock browser
 * set some cookies in mock browser
 * use cookies in mock browser
 * remove a cookie from mock browser

Restarting the browser will destroy *all* (session) cookies, which doesn't accurately reflect the behaviour I'm trying to simulate

Thanks

Taras

> 
> 
> 
>       
> --------------------------------------------------------------
> -----------
> This SF.Net email is sponsored by the Moblin Your Move 
> Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & 
> win great prizes
> Grand prize is a trip for two to an Open Source event 
> anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Simpletest-support mailing list
> Sim...@li...
> https://lists.sourceforge.net/lists/listinfo/simpletest-support
> 

Practical Law Company Limited. Registered in England and Wales. Registered Number: 02889191. Registered Office: 19 Hatfields, London SE1 8DJ. Telephone: +44(0)20 7202 1200. http://www.practicallaw.com. DISCLAIMERS: This e-mail is confidential to the ordinary user of the e-mail address to which it was addressed; it may contain personal views which are not the views of PLC unless specifically stated.  If you have received it in error, please delete it from your system and notify the sender immediately; do not use, copy or disclose the information or otherwise use it or any part of it in any form whatsoever nor act in reliance on it.  All liability for loss or damage caused by viruses is excluded.  PLC uses the MessageLabs SkyScan service to monitor all outgoing and incoming e-mails for viruses, prohibited file-type attachments and inappropriate content in accordance with its Information and Communications Systems policy.  You signify your consent to these terms by any further e-mail communication.

Save a tree...please don't print this e-mail unless you really need to.

Re: [Simpletest-support] Deleting a cookie

[Jason S. <jsw...@ya...>]

----- Original Message ----

From: Marcus Baker <ma...@wo...>

Taras Diakiw wrote:
> How do you delete a particular cookie?

This is a thorny one, as the browsers don't necessarily do this 
either. SimpleTest acts like a fussy (Netscape) browser. You have to 
explicitly set a timeout.

The FF Web Developers Toolbar allows you to delete all cookies for the current domain, but this behavior can be easily duplicated by just starting a new SimpleBrowser with no cookies to begin with.

Regards,
Jason



      

Re: [Simpletest-support] Where is the dom tester?

[Jason S. <jsw...@ya...>]

----- Original Message ----

From: Perrick Penet <pe...@no...>
Now browsing the API docs, I get a feeling the confusion comes from there.

http://simpletest.org/api/

The "un-released" alert is not present and the DomTestCase is on its 
own. I've updated another of the docblocks : I hope it'll be enough for 
the next publication of the API docs.

Yours,
    Perrick

Hi Perrick,

I have only been building the docs for the public site at the time of a package release, so what is up there is what was in the docblocks at the time of the package release. (I try to pay attention to the list for when this is happening so I can tidy up the docblocks just before a release, time permitting)  I am in a bit of a quandary as to what we should do in the case of a "bug" in the released docs.  I guess the correct thing to do would be to fix in both the "release" branch and in the trunk and republish the docs based on the "release" branch.

Regards,
Jason



      

Re: [Simpletest-support] Deleting a cookie

[Taras D. <Tar...@pr...>]

Hi again ;)

> -----Original Message-----
> From: sim...@li...
> [mailto:sim...@li...]On Behalf Of
> Marcus Baker
> Sent: 08 September 2008 14:29
> To: Help, advice, bugs and workarounds
> Subject: Re: [Simpletest-support] Deleting a cookie
> 
...
> 
> > 
> > Your thoughts?
> 
> Probably this should become a bug report, as I'll need to test again 
> in the wild with the most popular browsers. They shouldn't be, but 
> cookies are so unsimple.
> 
> I have a nasty suspicion that your sign-up code should set the 
> cookie to blank as well as set the date. All this strange behaviour 
> was very deliberately added to emulate old browsers. It's possible 
> that in real life the header really is like that.
> 
> Can you do the sign-up process in a real browser for now? Or does 
> this fail too?
> 
> 

Well I"m actually trying to test the destroying of the cookie upon logout. This is required in the single logout environment to indicate to the other web services that the user has been logged out.

I have tested expiring the cookie in FF3 and IE6 and it works as expected in both (it doesn't send expired cookie values).

I'm not sure if it's relevant, but the PHP manual at http://uk3.php.net/manual/en/function.setcookie.php states that to 'delete' a cookie you should expire it, so I'm guessing this is a pretty common behaviour:

"When deleting a cookie you should assure that the expiration date is in the past, to trigger the removal mechanism in your browser. Examples follow how to delete cookies sent in previous example: "

Taras


> 
> --------------------------------------------------------------
> -----------
> This SF.Net email is sponsored by the Moblin Your Move 
> Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & 
> win great prizes
> Grand prize is a trip for two to an Open Source event 
> anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Simpletest-support mailing list
> Sim...@li...
> https://lists.sourceforge.net/lists/listinfo/simpletest-support
> 

Practical Law Company Limited. Registered in England and Wales. Registered Number: 02889191. Registered Office: 19 Hatfields, London SE1 8DJ. Telephone: +44(0)20 7202 1200. http://www.practicallaw.com. DISCLAIMERS: This e-mail is confidential to the ordinary user of the e-mail address to which it was addressed; it may contain personal views which are not the views of PLC unless specifically stated.  If you have received it in error, please delete it from your system and notify the sender immediately; do not use, copy or disclose the information or otherwise use it or any part of it in any form whatsoever nor act in reliance on it.  All liability for loss or damage caused by viruses is excluded.  PLC uses the MessageLabs SkyScan service to monitor all outgoing and incoming e-mails for viruses, prohibited file-type attachments and inappropriate content in accordance with its Information and Communications Systems policy.  You signify your consent to these terms by any further e-mail communication.

Save a tree...please don't print this e-mail unless you really need to.

Re: [Simpletest-support] Deleting a cookie

[Marcus B. <ma...@wo...>]

Hi...

Taras Diakiw wrote:
> This function is only used in building up the header.. so I'd think that this fucntion should consider the expiry times of the cookies

Interesting.

> 
> Your thoughts?

Probably this should become a bug report, as I'll need to test again 
in the wild with the most popular browsers. They shouldn't be, but 
cookies are so unsimple.

I have a nasty suspicion that your sign-up code should set the 
cookie to blank as well as set the date. All this strange behaviour 
was very deliberately added to emulate old browsers. It's possible 
that in real life the header really is like that.

Can you do the sign-up process in a real browser for now? Or does 
this fail too?

> 
> Taras

yours, Marcus

Re: [Simpletest-support] Where is the dom tester?

[Perrick P. <pe...@no...>]

Hi,

>> The DomTestCase is already marked as "un-released" in the documentation 
>> on the web site.
> 
> Ah cool!
> 
>> I'm now confused as where this confusion 
>> comes from...
> 
> And i've just added to it :).

Now browsing the API docs, I get a feeling the confusion comes from there.

http://simpletest.org/api/

The "un-released" alert is not present and the DomTestCase is on its 
own. I've updated another of the docblocks : I hope it'll be enough for 
the next publication of the API docs.

Yours,
	Perrick