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.
