1) In the case of Progres Thru Processors the login is Facebook's, which they know. PTP links that through to the GR/BOINC user in the background. Apologies for not making that clear.
2) The client could poll for a few hours max, after which it could wait until the next time it's started up and then poll once and if necessary try the whole thing again. - I notice that other software sometimes fires up a browser window e.g. for feedback after uninstalling. Granted that example is not critical, but with the right UI I think it should be robust. For example if the first attempt failed, the client could show a window containing a link with a text like "Add this computer to your Progress Thru Processors (*or whatever*) account to get going (opens a browser window)". - No user interaction is required unless the browser is no longer logged in. - I'm not aware of any plugins/AVs etc that would interfere with this process unless an AV identified the URL as suspect, in which case we're probably stuffed anyway. - Rather than being browser-dependent it should be future-proof. 5) Interesting. There's a discussion about UUID uniquness in stackoverflow here <http://stackoverflow.com/questions/1155008/how-unique-is-uuid>. Hugh On 28 September 2015 at 16:48, Rom Walton <[email protected]> wrote: > > > 1. In the case of Progress Thru Processors, it is a catastrophic > failure case. Volunteers do not know what username/password they have been > assigned. > > > > 2-4. How long should the client poll before assuming an error has > occurred? All the various browser issues exist with plugins getting in the > way plus now you might have window z-orders to worry about. What happens > if the manager is over the browser window when it is looking for a > username/password? What happens if the browser window is stuck behind a > word processing application? > > > > 5. They do happen though. After deploying a test framework for a web > property on a project I previously worked on, we would experience a 50% > failure rate on test cases overnight every third day of testing. While the > math says one thing it is still something that has to be accounted for. > Granted the likelihood drops dramatically when they expire after a given > amount of time. But you still might run into denial of service attacks > accepting what amounts to random input from random locations on the > internet. Although, I suppose you could just ignore the GUID if the > session cookie is not available. > > > > Frankly, the more and more I think about this, the less and less I like > it. With browser cookie lookup we only had to deal with changes to three > browsers who more or less kept things somewhat predictable day to day. Now > we are trying to work into the equation any number of browsers and the > random factor of what the volunteer has configured (browser preferences, > virus scanners, anti-malware detectors, browser plugins) and how they are > using their system at the time of install. > > > > ----- Rom > > > > *From:* [email protected] [mailto:[email protected]] *On Behalf Of *Hugh > Wormington > *Sent:* Monday, September 28, 2015 5:22 AM > *To:* Rom Walton <[email protected]> > *Cc:* Hugh Wormington <[email protected]>; Matthew Blumberg < > [email protected]>; Rytis Slatkevičius <[email protected]>; BOINC > Developers Mailing List <[email protected]> > > *Subject:* Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs) > > > > 1. This shouldn't matter. If the session cookie is missing (ie user not > already logged into the website in that browser) then they will just be > asked to login. NB the current installer cookies should no longer be used > since the user identification comes from the website login. The user is > then greeted with some message like "this computer has been added to your > account". > > 2. to 4. I agree that approach seems unfeasible. I imagined the client > simply poll the AMS until its GUID is "claimed" by a user. Is that > feasible? > It might also be good to have the ability to "retry attach" to a user > account in case the original process didn't complete, maybe at boot time if > it finds itself unclaimed. A "retry" would simply involve reloading the > original browser URL. > > 5. GUIDs are widely used; the generator eg UUID ensures duplicates are so > rare that statistically they never happen. > > Hugh > > > > On 28 September 2015 at 01:44, Rom Walton <[email protected]> wrote: > > GUID would be more appropriate. > > > > I foresee a few problems with this approach though: > > 1. The ‘default’ browser wxWidgets detects may not be the browser > the volunteer downloaded BOINC with. > > 2. The manager would have to wait on the association to complete > which means it has to know how to deal with whatever browser to launched. > (Basically the manager would have to know how each browser works. (window > names, window class names, window titles, what events each window responds > too)) > (This is actually a more complicated problem than dealing with cookies.) > > 3. We may never be able to find out if the association was > successful from the manager perspective. > > 4. Some browser plugins redirect errors and monkey with the error > pages. (Norton 360, Google Toolbar, Yahoo Toolbar, etc.) > > 5. There is a remote possibility that two machines can generate the > same GUID, without being able to check against the master list ahead of > time it could happen. > > This solution might look okay from a server perspective, but it is a > monster from a client implementation perspective. > > > > ----- Rom > > > > > > *From:* [email protected] [mailto:[email protected]] *On Behalf Of *Hugh > Wormington > *Sent:* Sunday, September 27, 2015 5:22 PM > *To:* Rom Walton <[email protected]> > *Cc:* Matthew Blumberg <[email protected]>; Hugh Wormington < > [email protected]>; Rytis Slatkevičius <[email protected]>; > BOINC Developers Mailing List <[email protected]> > > > *Subject:* Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs) > > > > > Where is the nonce generated? > > By the installer. > > > > > If it is generated by the installer and passed to the account manager, > how to we know who it came from? > > The installer loads a browser on the url passing the "nonce" as a url > parameter. The receiving page is then able to associate it with a logged-in > user, after which the association is known. > > > > A little side issue for avoidance of lexical confusion.... I'm a little > unsure if this is really a "nonce" : > > - *Nonce:* is an arbitrary number that may only be used once in secure > communication exchange (See diagram on this wikipedia page > <https://en.wikipedia.org/wiki/Cryptographic_nonce>) It doesn't carry > any information itself. > - *GUID: *A globally unique identifier (GUID, /ˈɡuːɪd/) is a unique > reference number used as an identifier in computer software. The term > "GUID" typically refers to various implementations of the universally > unique identifier > <https://en.wikipedia.org/wiki/Universally_unique_identifier> (UUID) > standard (Wikipedia > <https://en.wikipedia.org/wiki/Globally_unique_identifier>) > > I think we're talking about a GUID which the installer generates at > install time and uses to identify itself to two different processes 1) the > front end web application 2) the account manager server. > > (A CPID is a kind of GUID, but this one isn't a CPID, since CPIDs are > (AFAIK) generated by the BOINC project servers.) > > > > So is it a nonce or a GUID? > > Hugh > > > > PS Many apologies if I'm teaching grandmothers to suck eggs (does that > work internationally??). > > > > On 26 September 2015 at 02:56, Rom Walton <[email protected]> wrote: > > In theory we could open up a browser with a URL like that. > > > > Where is the nonce generated? > > > > If it is generated from the account manager, how does the installer find > it? > > > > If it is generated by the installer and passed to the account manager, how > to we know who it came from? > > > > ----- Rom > > > > *From:* [email protected] [mailto:[email protected]] *On Behalf > Of *Matthew Blumberg > *Sent:* Friday, September 25, 2015 6:27 PM > *To:* Rom Walton <[email protected]> > *Cc:* Hugh Wormington <[email protected]>; Rytis Slatkevičius < > [email protected]>; BOINC Developers Mailing List < > [email protected]> > > > *Subject:* Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs) > > > > So for GR/CE/PTP you end up with filenames like: > gr_setup_asc_ODU0NjVfZWEwYWJkNjc4NDc2MjllMWFlOWVkM2I4YWRmZmZmZmY=.exe > > > > > > i'm really not comfortable with filenames like that > > > > for AMS, is it possible to : > > 1. open a browser window upon completion of install (*as is done > already); but instead of using return_url from the cookie, use instead the > URL from acct_mgr_url.xml, and append a random number as a parameter, e.g. > http://acctmgr.com/?return_id=[nonce] > 2. and then also use that same return_id as the user email address > (e.g. as of the user had entered this into the email field when registering > manually) > > > > (*tristan/rytis/hught, pls add any clarification if i'm missing something > or got something wrong) > > > > > > > > > > > > On Fri, Sep 25, 2015 at 10:21 AM, Rom Walton <[email protected]> wrote: > > A point of clarification. > > Everything the client needs to communicate with a project/account manager > will be in project_init.xml or acct_mgr_url.xml. > > All that will be missing to do an attach is an authenticator. > > ----- Rom > > -----Original Message----- > From: boinc_dev [mailto:[email protected]] On Behalf Of > Rom Walton > Sent: Friday, September 25, 2015 10:02 AM > To: Hugh Wormington <[email protected]>; Rytis Slatkevičius < > [email protected]> > Cc: Matthew Blumberg <[email protected]>; BOINC Developers Mailing > List <[email protected]> > Subject: Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs) > > In essence this is what the setup cookie is for. > > In cases where there is a customized installer, everything the client > needs will be in the project_init.xml or acct_mgr_url.xml (in the case of > account managers) files. BOINC will treat the setup cookie as opaque data > and just send it back to > https://<project_url>/lookup_account.php<https://%3cproject_url%3e/lookup_account.php > <https://%3cproject_url%3e/lookup_account.php%3chttps:/%3cproject_url%3e/lookup_account.php> > >. > > So for GR/CE/PTP you end up with filenames like: > gr_setup_asc_ODU0NjVfZWEwYWJkNjc4NDc2MjllMWFlOWVkM2I4YWRmZmZmZmY=.exe > > The filename can be made shorter as it depends on how large you want your > random piece of data to be. > > ----- Rom > > From: [email protected] [mailto:[email protected]] On Behalf Of Hugh > Wormington > Sent: Friday, September 25, 2015 6:56 AM > To: Rytis Slatkevičius <[email protected]> > Cc: Matthew Blumberg <[email protected]>; Rom Walton <[email protected]>; > BOINC Developers Mailing List <[email protected]>; Tristan Olive > <[email protected]>; Hugh Wormington <[email protected]> > Subject: Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs) > > Further to Rytis's email (is this the place to continue this discussion or > in Jira?): > I agree, but I think the stored meta data need not include user info, only > the project url. The installer would load a page on boinc.berkeley.edu< > http://boinc.berkeley.edu> in a browser, passing the nonce or cipid or > guid as a URL parameter (whichever variant is adopted). That in turn would > forward it to the project site. At this point the project site could > receive the cookies it set earlier (private and secure), and the > nonce/cipid/guid and continue the process. If it finds no cookies it can > ask the user to log in to the project site and then continue. > Hugh > > On 25 September 2015 at 07:48, Rytis Slatkevičius <[email protected] > <mailto:[email protected]>> wrote: > Is there really a need for such schemes? > > A script will be running to generate the download filenames (I assume at > boinc.berkeley.edu<http://boinc.berkeley.edu>); why not store user's > temporary metadata on the server instead of passing it through the > installer filename, and look it up based on the IP address? There are not > going to be any clashes if metadata is stored for only a short while. > > The process would be as follows: > 1. The user registers at a website; > 2. The website sends an RPC to boinc.berkeley.edu< > http://boinc.berkeley.edu> (or other URLs, e.g. in case of a custom > build), storing metadata as well as user's IP address; 3. The user > downloads a regular installation file and installs; 4. Once installed, the > first thing the client does is contact boinc.berkeley.edu< > http://boinc.berkeley.edu> to retrieve metadata and attach wherever > needed (maybe even possible through the installer?). The server would load > data based on the requester's IP address. > > > -- > Pagarbiai / Sincerely > Rytis Slatkevičius > +370 670 77777<tel:%2B370%20670%2077777 <%2B370%20670%2077777>> > > On Fri, Sep 25, 2015 at 12:28 AM, Matthew Blumberg <[email protected] > <mailto:[email protected]>> wrote: > I'm a little worried about the proposed approach; I fear it will notably > reduce conversion-completion rates -- if i got an installer with a 120 > character filename, i'd [a] edit to clean it up, and/or [b] assume it was > corrupted or infected and be afraid to run it. > > In any event, by way of making this work in the AMS context, can we > request one minor revision to the current scheme -- > > In the current scheme, at completion of install, the wizard opens a > browser window using the return_url specified in the browser cookie. Could > you instead open a browser window upon completion, using the URL from > acct_mgr_url.xml, and appending a random number as a parameter, e.g. > http://acctmgr.com/?return_id=[nonce]< > http://acctmgr.com/?return_id=%5bnonce%5d> > > Best Wishes, > > ..Matt > > > > > On Mon, Sep 21, 2015 at 10:59 AM, Rom Walton <[email protected]<mailto: > [email protected]>> wrote: > Howdy Folks, > > Current Strategy: > https://boinc.berkeley.edu/trac/wiki/SimpleAttach > > As part of the simplification process we (WCG and I) would like to propose > the idea of cookieless installs. > > See: > https://boinc.berkeley.edu/trac/wiki/SimpleAttach#CookielessInstalls > > Pros: > > We would be able to get around the various issues with cookies such as: > * Browser implementations changing over time. > * Sqlite changing over time > * Unknown browsers > > Cons: > > Realistically we are limited to filenames that are 256 characters in size. > > Note: By default various shells on Windows limit the file namespace to 256 > characters, the limits can by bypassed by prefixing the filename with > \\.\<file://./> but most users do not know that. I also suspect that > most browsers will complain about malware or something of that nature is we > attempt to go past 256 characters. > > ----- Rom > _______________________________________________ > boinc_dev mailing list > [email protected]<mailto:[email protected]> > > http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev > To unsubscribe, visit the above URL and > (near bottom of page) enter your email address. > > > > _______________________________________________ > boinc_dev mailing list > [email protected] > http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev > To unsubscribe, visit the above URL and > (near bottom of page) enter your email address. > _______________________________________________ > boinc_dev mailing list > [email protected] > http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev > To unsubscribe, visit the above URL and > (near bottom of page) enter your email address. > > > > > > > _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
