Hi All, Thanks for the feedback. I've installed the 3.2 Beta4 snapshot that was available. The cookie support is working fine using: disable_cookies: false I was able to log in to our WebGUI (highly recommended: http://www.plainblack.com/webgui) development site by using: start_url:http://www.mysite.org.au/?op=login&username=username&identifier=password (this approach also works for the Phprojekt component of the site). The cookies must have worked because Htdig was subsequently able to index protected pages.
As a first timer with Htdig my first impressions have been very positive with snappy performance and 90% of the functionality we require out of the box. Our site has multiple user and groups who can see diferent pages. They also need to be able to choose the type of information source: organisations, publications and/or discussions. I am currently intending to implement this by creating numerous different htdig databases created by searching select parts of the site with appropriate permissions. A wrapper script will combine several searches and order the results by category. The site is for an NGO in Melbourne, Australia that provides women's information services. Our approach is to make the search engine the primary source of public and internal information. Results with Htdig are encouraging. regards, Adam On Saturday 07 September 2002 07:09, Gabriele Bartolini wrote: > Ciao Gilles, > > thanks for pointing to the cookies patch. Yes, it is a backporting > patch from 3.2.x and works pretty well on my Linux system. I expect other > people on different platforms to test it and give me some feedback > regarding portability. > > As far as patch posting is concerned, I don't know whether Joe received > my e-mail 2 days ago. If you need more stuff please tell me, ok? > > >How you'd use that for authorisation may be another matter, though. > >I don't know if Gabriele's cookie support has a way of pre-loading cookies > >from another browser into htdig's cookie jar. Care to comment, Gabriele? > >(Or anyone else for that matter?) > > Well, to be sincere it is not a difficult thing. The code was designed > to support any kind of Cookies storage, it is pretty flexible indeed. For > now only the memory jar is supported. This regards though the persistency > of cookies among different crawls, which is different to the pre-loading of > cookies. This should not be a big work to do as I just said. > > We only need a format for storing them. We could decide this, if you > want. My vote would be to store them in a text file using the HTTP syntax. > By doing this, we would avoid any kind of parsing and the insertion into > the memory Jar would be straightforward. > > I don't know though if this is a flexible solution and the right one, > because it seems to go against the usual way of configuration and leads in > some cases to confusion (a user should use the specific and exact syntax in > order to issue one or more cookies). Any ideas? > > Ciao ciao and thanks for rising up the topic > -Gabriele ------------------------------------------------------- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 _______________________________________________ htdig-dev mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/htdig-dev
