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]<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 <[email protected]<mailto:[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]<mailto:[email protected]>] On Behalf Of Rom Walton Sent: Friday, September 25, 2015 10:02 AM To: Hugh Wormington <[email protected]<mailto:[email protected]>>; Rytis Slatkevičius <[email protected]<mailto:[email protected]>> Cc: Matthew Blumberg <[email protected]<mailto:[email protected]>>; BOINC Developers Mailing List <[email protected]<mailto:[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]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Hugh Wormington Sent: Friday, September 25, 2015 6:56 AM To: Rytis Slatkevičius <[email protected]<mailto:[email protected]>> Cc: Matthew Blumberg <[email protected]<mailto:[email protected]>>; Rom Walton <[email protected]<mailto:[email protected]>>; BOINC Developers Mailing List <[email protected]<mailto:[email protected]>>; Tristan Olive <[email protected]<mailto:[email protected]>>; Hugh Wormington <[email protected]<mailto:[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><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]><mailto:[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><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 <[email protected]<mailto:[email protected]><mailto:[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><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]><mailto:[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://./<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 [email protected]<mailto:[email protected]><mailto:[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]<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]<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.
