Re: Can Wget do client authentication? Can it be implemented?
Jon, I will check out the documentation. I had only checked on Wget's site, I had thought that all the same documentation would be there as well, but that what I get for assuming. Many thanks Bryan On Thu, 24 Feb 2005 02:22:30 +, Jonathan Share <[EMAIL PROTECTED]> wrote: > On Tue, 22 Feb 2005 19:09:11 +, Bryan <[EMAIL PROTECTED]> wrote: > > > > Automize cannot access PKI-enabled websites, as it does not support > > that functionality. I was reading up about Wget, and I saw that you > > can send a specific cookie back to a website. This is almost exactly > > what I am looking for, but instead of a cookie, it's a personal > > certificate, with an extension of .p12 . > > > > If anyone can tell me if that is something that is maybe coming up in > > later builds or if that functionality is already available, I would > > greatly appreciate it. > > Have you tried playing with the sslcertfile and/or sslcertkey parameters? > I don't seem to be able to find any documentation for these parameters > other than they are listed when you do a "wget --help" but I assume > their function is fairly self explanatory. > > HTH > > Jon >
Re: Can Wget do client authentication? Can it be implemented?
On Tue, 22 Feb 2005 19:09:11 +, Bryan <[EMAIL PROTECTED]> wrote: > > Automize cannot access PKI-enabled websites, as it does not support > that functionality. I was reading up about Wget, and I saw that you > can send a specific cookie back to a website. This is almost exactly > what I am looking for, but instead of a cookie, it's a personal > certificate, with an extension of .p12 . > > If anyone can tell me if that is something that is maybe coming up in > later builds or if that functionality is already available, I would > greatly appreciate it. Have you tried playing with the sslcertfile and/or sslcertkey parameters? I don't seem to be able to find any documentation for these parameters other than they are listed when you do a "wget --help" but I assume their function is fairly self explanatory. HTH Jon
Re: Can Wget do client authentication? Can it be implemented?
Did I ask the wrong question? I mean, it's not uncommon to ask about the feasibility of adding new functionality. If I am posting on the wrong list, I apologize. Bryan On Tue, 22 Feb 2005 19:09:11 +, Bryan <[EMAIL PROTECTED]> wrote: > I work as a webmaster for a US Government agency. We currently use a > program called "Automize" to do everything that wget could do for us. > Many government websites require a client certificate (called PKI) to > access the website. Basically, it lets websites verify that the > person is who they say they are. > > Automize cannot access PKI-enabled websites, as it does not support > that functionality. I was reading up about Wget, and I saw that you > can send a specific cookie back to a website. This is almost exactly > what I am looking for, but instead of a cookie, it's a personal > certificate, with an extension of .p12 . > > I am not a code writer, I just like great programs. I can't find > anything that sends does client auth that would allow me to get > content off of those sites. > > If anyone can tell me if that is something that is maybe coming up in > later builds or if that functionality is already available, I would > greatly appreciate it. > > Also, I realize money talks to developers. If someone was to donate > to the development (I know how much beer and Taco bell costs :P) would > that make it more possible of this feature being added??? > > Just asking... thanks for answering... > > Bryan >
Re: O_EXCL and large files
On Wed, 23 Feb 2005, Hrvoje Niksic wrote: > I see. Now I know why I didn't use AC_FUNC_FSEEKO -- Wget doesn't use > fseeko anywhere. The only usage we have is: > > fseek (fp, 0, SEEK_END); > size = ftell (fp); /* replaced with ftello where available */ > > Is there need to use fseeko here? Probably -- the Single Unix Specification, Version 2, which introduced the "o" functions, quotes this error code: [EOVERFLOW] For fseek(), the resulting file offset would be a value which cannot be represented correctly in an object of type long. I don't know if it happens in practice (GNU libc seems to be forgiving, as usual). But we do want to use ftello(), so we need AC_FUNC_FSEEKO anyway as the _LARGEFILE_SOURCE restriction applies to both. This is what autoconf manual says (yes, a reference to ftello() should really be included in the AC_FUNC_FSEEKO description): The LFS introduced the `fseeko' and `ftello' functions to replace their C counterparts `fseek' and `ftell' that do not use `off_t'. Take care to use `AC_FUNC_FSEEKO' to make their prototypes available when using them and large-file support is enabled. And if using ftello(), then we should probably use fseeko() as well, for consistency if nothing else. Maciej
Re: O_EXCL and large files
"Maciej W. Rozycki" <[EMAIL PROTECTED]> writes: >> I wonder what is the difference between AC_FUNC_FSEEKO and >> AC_CHECK_FUNCS(seeko). The manual doesn't seem to explain. > > Well, that's what I have on my local system: > > - Macro: AC_FUNC_FSEEKO > If the `fseeko' function is available, define `HAVE_FSEEKO'. > Define `_LARGEFILE_SOURCE' if necessary to make the prototype > visible on some systems (e.g. glibc 2.2). Otherwise linkage > problems may occur when compiling with `AC_SYS_LARGEFILE' on > largefile-sensitive systems where `off_t' does not default to a > 64bit entity. > > The "_LARGEFILE_SOURCE" bit is the important one -- I have a vague > memory of some program having a problem once in this area. I see. Now I know why I didn't use AC_FUNC_FSEEKO -- Wget doesn't use fseeko anywhere. The only usage we have is: fseek (fp, 0, SEEK_END); size = ftell (fp); /* replaced with ftello where available */ Is there need to use fseeko here?
Re: O_EXCL and large files
On Wed, 23 Feb 2005, Hrvoje Niksic wrote: > > You may also want AC_FUNC_FSEEKO for fseeko(). > > I wonder what is the difference between AC_FUNC_FSEEKO and > AC_CHECK_FUNCS(seeko). The manual doesn't seem to explain. Well, that's what I have on my local system: - Macro: AC_FUNC_FSEEKO If the `fseeko' function is available, define `HAVE_FSEEKO'. Define `_LARGEFILE_SOURCE' if necessary to make the prototype visible on some systems (e.g. glibc 2.2). Otherwise linkage problems may occur when compiling with `AC_SYS_LARGEFILE' on largefile-sensitive systems where `off_t' does not default to a 64bit entity. The "_LARGEFILE_SOURCE" bit is the important one -- I have a vague memory of some program having a problem once in this area. > > I was already a bit surprised having failed to see AC_SYS_LARGEFILE > > being called from your patch, > > Are you sure you looked at my patch? All three versions of the patch > pretty much begin with the "+AC_SYS_LARGEFILE" change to configure.in. Well, I must have been blind. Or I'm simply too busy these days. Anyway, sorry about the confusion and I'm glad you've got this right despite the issues with LFS being too messy on many systems with no good reason. Maciej
Re: O_EXCL and large files
"Maciej W. Rozycki" <[EMAIL PROTECTED]> writes: >> Is it possible to portably use open() and retain large file support? > > Try the AC_SYS_LARGEFILE autoconf macro. That's what I thought I was using. I was just afraid that open() wasn't correctly encompassed by the large file API's, a fear that proved unfounded. > You may also want AC_FUNC_FSEEKO for fseeko(). I wonder what is the difference between AC_FUNC_FSEEKO and AC_CHECK_FUNCS(seeko). The manual doesn't seem to explain. > I was already a bit surprised having failed to see AC_SYS_LARGEFILE > being called from your patch, Are you sure you looked at my patch? All three versions of the patch pretty much begin with the "+AC_SYS_LARGEFILE" change to configure.in.
Re: string_t breaks compilation under Solaris
Simone Piunno <[EMAIL PROTECTED]> writes: > On Tuesday 22 February 2005 00:10, Hrvoje Niksic wrote: > >> If wide chars were in that message, you could no longer print it with >> printf, which means that a majority of gettext-using programs would be >> utterly broken, Wget included. I imagine I would have gotten a bunch >> of bug reports for that kind of thing in the 7 or so years that Wget >> has been using gettext. > > I have an interesting tale to tell. Your tale depicts a somewhat different scenario -- you switched to UTF-8 and things broke. This should not happen because UTF-8 was specifically designed to be mixable with ASCII and thus meet the needs of (among others) Wget. That is quite different from switching to an ASCII-incompatible locale. > So what I wanted to say is that your point of view is OK, cause as > long as nobody complains you can *pretend* the problem is not there, If printf and strlen no longer work, it is IMO not Wget that has a problem, but the environment. You could say that it is Wget's problem that it doesn't adapt to a strange environment, but there is only so much one can do -- I've rejected EBCDIC patches too. To the best of my knowledge, Wget works fine in ASCII-compatible environments, which includes UTF-8. The only breakage is a theoretical one in environments where 99% of applications would break too. I don't speak for Mauro, but I can live with that.
Re: string_t breaks compilation under Solaris
On Tuesday 22 February 2005 00:10, Hrvoje Niksic wrote: > If wide chars were in that message, you could no longer print it with > printf, which means that a majority of gettext-using programs would be > utterly broken, Wget included. I imagine I would have gotten a bunch > of bug reports for that kind of thing in the 7 or so years that Wget > has been using gettext. I have an interesting tale to tell. Approx one year ago I switched locale from it_IT.ISO-8859-1 to it_IT.UTF-8. Since then, almost everything has been fine, except a few application having some visualization or interaction problem. I never reported them cause I was conviced it was my problem, some misconfiguration of something. This week I had enough time to tinker, so I've tried to figure out why I get this answer when asking for a non-existent man page: [EMAIL PROTECTED] ~ $ man doesntexist Non c'ïuna voce per doesntexist You see? There's a square symbol between "Non c'" and "una voce". It's an encoding failure. If it worked, it would read: [EMAIL PROTECTED] ~ $ man doesntexist Non c'Ã una voce per doesntexist Looking at man code I've found it still uses catget, a translation tool older than gettext. The italian translation file is written in iso-8859-1 and catget doesn't convert it to my locale on the fly (as gettext would), so here is the bug. Everybody using a locale with a charset encoding different than the only one supported would hit the problem, not just italian/utf-8. After reporting to the man maintainer I've discovered: 1. he never got complaints in the many years after translation 2. he wasn't aware of the problem 3. he would be happy to switch to gettext to fix it So what I wanted to say is that your point of view is OK, cause as long as nobody complains you can *pretend* the problem is not there, but this doesn't make the problem vanish automatically ;) Sooner or later, someone will hit it, or maybe some people already hit it all the time but they don't realize it's a bug. -- Adde parvum parvo magnus acervus erit -- Ovidio
Re: O_EXCL and large files
On Tue, 22 Feb 2005, Hrvoje Niksic wrote: > However, I suspect that this will not work correctly with large files. > strace shows that, when large files are used, Linux fopen includes > O_LARGEFILE among the flags. Solaris, on the other hand, seems to use > the open64 function. (But will open be automatically mapped to open64 > when _FILE_OFFSET_BITS is 64?) For all I know, other systems may > require something different. > > Is it possible to portably use open() and retain large file support? Try the AC_SYS_LARGEFILE autoconf macro. It has the advantage of being the standard way of adding support for LFS these days and thus is supposed to work for all systems that are in use by a reasonable number of people (and the others can provide fixes directly to autoconf, whether they use wget or not -- you just need to keep your autoconf you're making releases with up to date, which is an expected practice anyway). It also has a side effect of providing the "--disable-largefile" configure option, which may be useful for some people. The macro is reasonably documented in the autoconf manual (as of 2.59, at least). It's used by GNU coreutils among others, which are about the most extensive users of all kinds of file-related calls. You may also want AC_FUNC_FSEEKO for fseeko(). I was already a bit surprised having failed to see AC_SYS_LARGEFILE being called from your patch, but I haven't had time to do any testing yet, so I hesitated making any comments, sorry. Maciej
