2) So the volunteer is supposed to leave the manager alone for a few hours while it is stuck in the attach wizard bouncing a ball between two computers?
I suspect that is not what you had in mind. The whole reason for the wizards existence is to provide the client software with an authenticator to attach to a project/account manager with when completed. If we leave the wizard and begin some background operation in the client, then the volunteer gets an empty UI not doing anything as far as they can tell. They would have to go to the event log (Advanced UI thing) just to see what the client is up too. Behind the wizard this is what is going on: 1. Get Project Config RPC (Run in Manager): detect various things about a project/account manager. Minimum password lengths, platforms supported, canonical project URL, etc. 2. Lookup Account/Create Account (Run in Manager): get the volunteer to give us enough information to acquire an authenticator. 3. Attach to project (Run in Client): when the wizard closes it instructs the client to attach to a project with the given authenticator. Once the client begins the attach process, the UI sees a project. It can display some information about it. Originally I envisioned this as something interjected between steps 1 and 2, when the browser window is closed, it passes the GUID to the lookup account phase and proceeds based on success or failure. What your proposing is to push more of the attach process into the client so the attach process can move between its states without the wizard being stuck displaying the bouncing ball between two computers. It would require a major overhaul of the client/manager-side attach process to support. ----- Rom From: hugh.w...@gmail.com [mailto:hugh.w...@gmail.com] On Behalf Of Hugh Wormington Sent: Monday, September 28, 2015 12:35 PM To: Rom Walton <r...@romwnet.org> Cc: Hugh Wormington <h...@gridrepublic.org>; Matthew Blumberg <m...@gridrepublic.org>; Rytis Slatkevičius <ry...@gridrepublic.org>; BOINC Developers Mailing List <boinc_dev@ssl.berkeley.edu> Subject: Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs) 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 <r...@romwnet.org<mailto:r...@romwnet.org>> 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: hugh.w...@gmail.com<mailto:hugh.w...@gmail.com> [mailto:hugh.w...@gmail.com<mailto:hugh.w...@gmail.com>] On Behalf Of Hugh Wormington Sent: Monday, September 28, 2015 5:22 AM To: Rom Walton <r...@romwnet.org<mailto:r...@romwnet.org>> Cc: Hugh Wormington <h...@gridrepublic.org<mailto:h...@gridrepublic.org>>; Matthew Blumberg <m...@gridrepublic.org<mailto:m...@gridrepublic.org>>; Rytis Slatkevičius <ry...@gridrepublic.org<mailto:ry...@gridrepublic.org>>; BOINC Developers Mailing List <boinc_dev@ssl.berkeley.edu<mailto:boinc_dev@ssl.berkeley.edu>> 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. [https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif]Hugh On 28 September 2015 at 01:44, Rom Walton <r...@romwnet.org<mailto:r...@romwnet.org>> 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: hugh.w...@gmail.com<mailto:hugh.w...@gmail.com> [mailto:hugh.w...@gmail.com<mailto:hugh.w...@gmail.com>] On Behalf Of Hugh Wormington Sent: Sunday, September 27, 2015 5:22 PM To: Rom Walton <r...@romwnet.org<mailto:r...@romwnet.org>> Cc: Matthew Blumberg <m...@gridrepublic.org<mailto:m...@gridrepublic.org>>; Hugh Wormington <h...@gridrepublic.org<mailto:h...@gridrepublic.org>>; Rytis Slatkevičius <ry...@gridrepublic.org<mailto:ry...@gridrepublic.org>>; BOINC Developers Mailing List <boinc_dev@ssl.berkeley.edu<mailto:boinc_dev@ssl.berkeley.edu>> 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 <r...@romwnet.org<mailto:r...@romwnet.org>> 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: mblumb...@picador.net<mailto:mblumb...@picador.net> [mailto:mblumb...@picador.net<mailto:mblumb...@picador.net>] On Behalf Of Matthew Blumberg Sent: Friday, September 25, 2015 6:27 PM To: Rom Walton <r...@romwnet.org<mailto:r...@romwnet.org>> Cc: Hugh Wormington <h...@gridrepublic.org<mailto:h...@gridrepublic.org>>; Rytis Slatkevičius <ry...@gridrepublic.org<mailto:ry...@gridrepublic.org>>; BOINC Developers Mailing List <boinc_dev@ssl.berkeley.edu<mailto:boinc_dev@ssl.berkeley.edu>> 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]<http://acctmgr.com/?return_id=%5bnonce%5d> 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 <r...@romwnet.org<mailto:r...@romwnet.org>> 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:boinc_dev-boun...@ssl.berkeley.edu<mailto:boinc_dev-boun...@ssl.berkeley.edu>] On Behalf Of Rom Walton Sent: Friday, September 25, 2015 10:02 AM To: Hugh Wormington <h...@gridrepublic.org<mailto:h...@gridrepublic.org>>; Rytis Slatkevičius <ry...@gridrepublic.org<mailto:ry...@gridrepublic.org>> Cc: Matthew Blumberg <m...@gridrepublic.org<mailto:m...@gridrepublic.org>>; BOINC Developers Mailing List <boinc_dev@ssl.berkeley.edu<mailto:boinc_dev@ssl.berkeley.edu>> 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: hugh.w...@gmail.com<mailto:hugh.w...@gmail.com> [mailto:hugh.w...@gmail.com<mailto:hugh.w...@gmail.com>] On Behalf Of Hugh Wormington Sent: Friday, September 25, 2015 6:56 AM To: Rytis Slatkevičius <ry...@gridrepublic.org<mailto:ry...@gridrepublic.org>> Cc: Matthew Blumberg <m...@gridrepublic.org<mailto:m...@gridrepublic.org>>; Rom Walton <r...@romwnet.org<mailto:r...@romwnet.org>>; BOINC Developers Mailing List <boinc_dev@ssl.berkeley.edu<mailto:boinc_dev@ssl.berkeley.edu>>; Tristan Olive <tol...@gridrepublic.org<mailto:tol...@gridrepublic.org>>; Hugh Wormington <h...@gridrepublic.org<mailto:h...@gridrepublic.org>> 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><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 <ry...@gridrepublic.org<mailto:ry...@gridrepublic.org><mailto:ry...@gridrepublic.org<mailto:ry...@gridrepublic.org>>> 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><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><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><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><tel:%2B370%20670%2077777> On Fri, Sep 25, 2015 at 12:28 AM, Matthew Blumberg <m...@gridrepublic.org<mailto:m...@gridrepublic.org><mailto:m...@gridrepublic.org<mailto:m...@gridrepublic.org>>> 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><http://acctmgr.com/?return_id=%5bnonce%5d> Best Wishes, ..Matt On Mon, Sep 21, 2015 at 10:59 AM, Rom Walton <r...@romwnet.org<mailto:r...@romwnet.org><mailto:r...@romwnet.org<mailto:r...@romwnet.org>>> 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://./<file://./%3cfile:/>> 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 boinc_dev@ssl.berkeley.edu<mailto:boinc_dev@ssl.berkeley.edu><mailto:boinc_dev@ssl.berkeley.edu<mailto:boinc_dev@ssl.berkeley.edu>> 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 boinc_dev@ssl.berkeley.edu<mailto:boinc_dev@ssl.berkeley.edu> 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 boinc_dev@ssl.berkeley.edu<mailto:boinc_dev@ssl.berkeley.edu> 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 boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
![https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif]Hugh](https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif]Hugh){kind=link}