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.
