Yes, Rom.
It really seems like a monster on the client side. This is
neither easy nor error-proof.
So, ... :
Why not to save the unique "GUID" (generated by the server) + all
this info (with perfectly encrypted password) in a dedicated *(MySQL)
DATABASE* on the main BOINC web-server? (it could be easily "cron"-ned to
be cleaned from old entries and Vacuum-analyzed every 4 hours or so)
It would be browser-independent. IT would be easily
implemented as temporary and as *valid only for the given I.P. address* -
which is the same (during a short interval like 1 hour) across all
browsers on the PC / VM , as far as I know.
Namaste
Filip
2015-09-28 2:44 GMT+02:00 Rom Walton <[email protected]>:
> GUID would be more appropriate.
>
> I foresee a few problems with this approach though:
>
> 1. The ‘default’ browser wxWidgets detects may not be the browser
> the volunteer downloaded BOINC with.
>
> 2. The manager would have to wait on the association to complete
> which means it has to know how to deal with whatever browser to launched.
> (Basically the manager would have to know how each browser works. (window
> names, window class names, window titles, what events each window responds
> too))
> (This is actually a more complicated problem than dealing with cookies.)
>
> 3. We may never be able to find out if the association was
> successful from the manager perspective.
>
> 4. Some browser plugins redirect errors and monkey with the error
> pages. (Norton 360, Google Toolbar, Yahoo Toolbar, etc.)
>
> 5. There is a remote possibility that two machines can generate the
> same GUID, without being able to check against the master list ahead of
> time it could happen.
>
> This solution might look okay from a server perspective, but it is a
> monster from a client implementation perspective.
>
> ----- Rom
>
>
> From: [email protected] [mailto:[email protected]] On Behalf Of Hugh
> Wormington
> Sent: Sunday, September 27, 2015 5:22 PM
> To: Rom Walton <[email protected]>
> Cc: Matthew Blumberg <[email protected]>; Hugh Wormington <
> [email protected]>; Rytis Slatkevičius <[email protected]>;
> BOINC Developers Mailing List <[email protected]>
> Subject: Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs)
>
> > Where is the nonce generated?
> By the installer.
>
> > If it is generated by the installer and passed to the account manager,
> how to we know who it came from?
> The installer loads a browser on the url passing the "nonce" as a url
> parameter. The receiving page is then able to associate it with a logged-in
> user, after which the association is known.
>
> A little side issue for avoidance of lexical confusion.... I'm a little
> unsure if this is really a "nonce" :
>
> * Nonce: is an arbitrary number that may only be used once in secure
> communication exchange (See diagram on this wikipedia page<
> https://en.wikipedia.org/wiki/Cryptographic_nonce>) It doesn't carry any
> information itself.
> * GUID: A globally unique identifier (GUID, /ˈɡuːɪd/) is a unique
> reference number used as an identifier in computer software. The term
> "GUID" typically refers to various implementations of the universally
> unique identifier<
> https://en.wikipedia.org/wiki/Universally_unique_identifier> (UUID)
> standard (Wikipedia<
> https://en.wikipedia.org/wiki/Globally_unique_identifier>)
>
> I think we're talking about a GUID which the installer generates at
> install time and uses to identify itself to two different processes 1) the
> front end web application 2) the account manager server.
> (A CPID is a kind of GUID, but this one isn't a CPID, since CPIDs are
> (AFAIK) generated by the BOINC project servers.)
>
> So is it a nonce or a GUID?
> Hugh
>
> PS Many apologies if I'm teaching grandmothers to suck eggs (does that
> work internationally??).
>
> On 26 September 2015 at 02:56, Rom Walton <[email protected]<mailto:
> [email protected]>> wrote:
> 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]> [mailto:
> [email protected]<mailto:[email protected]>] On Behalf Of Matthew
> Blumberg
> Sent: Friday, September 25, 2015 6:27 PM
> To: Rom Walton <[email protected]<mailto:[email protected]>>
> Cc: Hugh Wormington <[email protected]<mailto:[email protected]>>;
> Rytis Slatkevičius <[email protected]<mailto:[email protected]>>;
> BOINC Developers Mailing List <[email protected]<mailto:
> [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.
>
_______________________________________________
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.
