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] On Behalf Of Rom Walton Sent: Friday, September 25, 2015 10:02 AM To: Hugh Wormington <h...@gridrepublic.org>; Rytis Slatkevičius <ry...@gridrepublic.org> Cc: Matthew Blumberg <m...@gridrepublic.org>; BOINC Developers Mailing List <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>. 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] On Behalf Of Hugh Wormington Sent: Friday, September 25, 2015 6:56 AM To: Rytis Slatkevičius <ry...@gridrepublic.org> Cc: Matthew Blumberg <m...@gridrepublic.org>; Rom Walton <r...@romwnet.org>; BOINC Developers Mailing List <boinc_dev@ssl.berkeley.edu>; Tristan Olive <tol...@gridrepublic.org>; Hugh Wormington <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> 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>> 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> On Fri, Sep 25, 2015 at 12:28 AM, Matthew Blumberg <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> Best Wishes, ..Matt On Mon, Sep 21, 2015 at 10:59 AM, Rom Walton <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://./> 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> 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. _______________________________________________ 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.
