Using IP addresses is kind of iffy, think a bunch of computers within a corporate environment. With a small company we probably wouldn't run into a problem. IBM or Microsoft, we probably would.
Cookies themselves are a weak point as the browsers are constantly changing and require us to update the cookie detection code. Over time things fall apart for the same BOINC version. Once the installer is code-signed, the contents of the installation package cannot be changed. If we had a static URL on the Internet that we point the installer to and it disappears, then that scheme falls apart. Encoding things within the file name avoids a single point of failure relative to the code-signed installer. The server-side code that handles the file rename process can run from whichever server the volunteer is downloading the installer from. ----- Rom -----Original Message----- From: boinc_dev [mailto:[email protected]] On Behalf Of Christian Beer Sent: Friday, September 25, 2015 8:40 AM To: [email protected] Subject: Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs) What Rytis suggests sounds good but relies on the availability of boinc.berkeley.edu which I consider a week point at the moment. Sending Web-RPCs is better than the cookie thing because we already support Web-RPC's and just need to define where to send the RPC to. We would need a permanent URL where the Client can get the metadata from that doesn't change because it is hardcoded in the Client/Installer. The IP lookup should work if the metadata expires within a few hours because the IP maybe reassigned to another user in the meantime. Sure the scenario to exploit this is unlikely but possible. MfG / Regards Christian Beer Am 25.09.2015 um 10:08 schrieb David Anderson: > That scheme sounds plausible, > but it seems more complex than what Rom proposed. > -- D > > On 9/24/2015 11:48 PM, Rytis Slatkevičius 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); 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 (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 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 >> >> On Fri, Sep 25, 2015 at 12:28 AM, Matthew Blumberg >> <[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] >>> >>> Best Wishes, >>> >>> ..Matt >>> >>> >>> >>> >>> On Mon, Sep 21, 2015 at 10:59 AM, Rom Walton <[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 >>>> \\.\ 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] >>>> 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. _______________________________________________ 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.
