On 2014-10-01 10:15-0700 Alan W. Irwin wrote: > The only real area left of concern is the method I use to authenticate > the POST by wget or curl. SF login is by form, and that complicates > matters tremendously as you can see from > <http://wget.addictivecode.org/FrequentlyAskedQuestions#How_do_I_use_wget_to_download_pages_or_files_that_require_login.2Fpassword.3F> > That link mentions the possibility of 4 different quantities (username > and password, but also two others) that typically must be specified, > but when I look at the text of the SF login page, with ctrl-U, it > looks like there are 6 quantities (6 <input> tags) to specify. > However, under certain circumstances (no "session" cookies where > cookie information is kept in browser memory rather than in a file) > you can take over an already existing login done by GUI by using its > cookie file. So I will try that simpler method first.
Authentication proved to be an absolute showstopper. The SF login form sets the _visit_cookie name to some random number, e.g., d7e064cfcaad6c62a7f3727b12a04e6a each time you attempt to login. This general "are you a human" design for login forms is specifically meant to keep users from using automated software such as wget and curl from logging in according to what I have read on the web. (I guess SF and the rest who use such login forms are concerned with the security of their server for POST methods or denial of service attack possibilities with wget and curl since they can POST file contents so rapidly and automatically.) With that avenue blocked, one other possibility was to borrow a cookie from an existing authenticated login. That possibility could not even be tried with firefox because their cookies are apparently kept in a mysql database rather than in a simple file. I did try that possibility with konqueror, but apparently there is "session" cookie information that is also used by the login form that does not appear in the konqueror cookies file because the uniform response from SF for all borrowed-cookie POST attempts was "not authorized". One other possibility here is to use a SF in-house solution for authentication called oauth. But currently it is so badly documented that it is impossible to figure out what to do. I hate to admit defeat here, but I think it is time to cut my losses and accept that cut and paste is the only way to fill in our ~50 wiki files at SF. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
