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.
