Ok. I'll try to look at this as well - but no promises about when I can do so...

-jms
Sent from my PDA. No type good.


From: Igor Ivanov <igor.ivanov@itseez.com>
To: Igor Ivanov <igor.ivanov@itseez.com>
Cc: bg@argus-cv.com <bg@argus-cv.com>; Igor Ivanov <igor.ivanov@argus-cv.com>; Development list for the MPI Testing Tool <mtt-devel@open-mpi.org>; mtt-devel-bounces@open-mpi.org <mtt-devel-bounces@open-mpi.org>; Mike Dubman <miked@voltaire.com>; Jeff Squyres (jsquyres)
Sent: Thu Mar 04 01:31:16 2010
Subject: Re: [MTT devel] MTToGDS



Igor Ivanov wrote:
I considered possibility to use cookie when issue was found out. But looking google documentation I could not understand if it solved this issue. So it require additional investigation that I do not have now. I will look in this way closer but current quick solutions were suggested in mail.
Now we have information about issue and know ways to workaround them.

Igor

Jeff Squyres wrote:
Yoinks.

Alternatively, doesn't a Google login return a cookie of some flavor that is valid for a long period of time (somewhere between 1 day and 2 weeks)?  Can't we keep/cache that cookie down in the MTT client and use it for subsequent data submissions until the cookie expires and we have to login again?


On Feb 27, 2010, at 8:30 AM, Igor Ivanov wrote:

  
Description:
Issue arises during submitting data frequently. We can get failure during data submitting with authentication error.

Reason:
Google allows a failure response on The ClientLogin authorization process with a CAPTCHA challenge means that Google has decided, for whatever reason, that additional security measures should be taken. This response is accompanied by a CAPTCHA image URL and a token representing the specific CAPTCHA challenge.
I do not see way to organize customer input in this case.

Detail information can be found at:
http://code.google.com/intl/en-EN/apis/accounts/docs/AuthForInstalledApps.html

Possible solutions:
1. catch error condition on server side and return status 503: 'Service Unavailable';
In this case client can organize processing of this failure (it is possible that sleeping for some time could help)
2. catch error condition on server side and accept authentication by correct username only w/o real verification;
3. rollback to previous scheme;


Igor

Igor Ivanov wrote:
    
Hi Jeff,

I am sending patch that enable google account approach to submit data to MTT GDS.
It also has the fix to a bug in displaying table as respond to bquery.pl --view (It has not been committed yet to MTT trunk).

As for question relating "how does one develop ..." that source information can be found at following location as: http://svn.open-mpi.org/svn/mtt/trunk/docs/gds/VBench_GDS_Setup.doc.
In case you make a resolve to accept patch I am sending next steps should be done:

1. update application on server side using instruction in VBench_GDS_Setup.doc (topic 4 "Installation")
example: appcfg.py update <local folder with open-mpi-mtt>/
2. change version on https://appengine.google.com/deployment?&app_id=open-mpi-mtt&version_id=1.337140739868725607 from 1 to 2 (make default)
note: after this operation all users that attempt to submit data using previous scheme of authentication will get failure respond.
3. go to open-mpi-mtt and add new users with google account


Regards,
Igor

Jeff Squyres wrote:
      
Great -- many thanks!

On Feb 12, 2010, at 12:32 PM, Igor Ivanov wrote:

  

        
Hi Jeff,

I have done changes related google account support but not tested them well.
I will try to send them on Monday.

Regards,
Igor

Jeff Squyres wrote:
    

          
On Feb 10, 2010, at 9:09 AM, Igor Ivanov wrote:

  

      

            
I took a swipe at doing this (totally not tested; how does one develop/test this stuff?).  I know just a tiny bit of python, but the code was fairly readable.  Please see the attached patch -- is it anywhere close to correct?

      

          

                
[II] It seems close but you forget about bquery.pl that allows to add a new user and related handler (processes bquery.pl --admin) on gds/main.py at least.
    

        

              
Oh, yikes -- good catch.  I'll look into that...

How does one develop / test / debug / deploy changes to this stuff?

  

      

            
__________ Information from ESET NOD32 Antivirus, version of virus signature database 4861 (20100212) __________

The message was checked by ESET NOD32 Antivirus.


http://www.esetnod32.ru

    

          
  

        
__________ Information from ESET NOD32 Antivirus, version of virus signature database 4871 (20100216) __________

The message was checked by ESET NOD32 Antivirus.

http://www.esetnod32.ru


__________ Information from ESET NOD32 Antivirus, version of virus signature database 4871 (20100216) __________

The message was checked by ESET NOD32 Antivirus.

http://www.esetnod32.ru

_______________________________________________
mtt-devel mailing list

mtt-devel@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel




__________ Information from ESET NOD32 Antivirus, version of virus signature database 4871 (20100216) __________

The message was checked by ESET NOD32 Antivirus.


http://www.esetnod32.ru



      
__________ Information from ESET NOD32 Antivirus, version of virus signature database 4899 (20100226) __________

The message was checked by ESET NOD32 Antivirus.

http://www.esetnod32.ru
    


  


__________ Information from ESET NOD32 Antivirus, version of virus signature database 4913 (20100303) __________

The message was checked by ESET NOD32 Antivirus.

http://www.esetnod32.ru


__________ Information from ESET NOD32 Antivirus, version of virus signature database 4913 (20100303) __________

The message was checked by ESET NOD32 Antivirus.

http://www.esetnod32.ru


__________ Information from ESET NOD32 Antivirus, version of virus signature database 4913 (20100303) __________

The message was checked by ESET NOD32 Antivirus.

http://www.esetnod32.ru