WinHTTrack login test fixtures ============================== Throwaway login pages for testing WinHTTrack's "Log in with a browser..." feature. That feature harvests the browser profile's cookies and hands them to the engine as a Netscape cookies.txt. None of this is a real account. Credentials, the same everywhere: user whtt-tester password fixture-pw-2026 URLs ---- Case 1, plain form login on one host: https://www.httrack.com/tests/login/basic/ https://www.httrack.com/tests/login/basic/protected/ https://www.httrack.com/tests/login/basic/protected/deep1.php https://www.httrack.com/tests/login/basic/protected/deep2.php https://www.httrack.com/tests/login/basic/protected/deep3.php Case 2, login and content across two hosts: https://httrack.com/tests/login/crosshost/ https://www.httrack.com/tests/login/crosshost/accept/ https://httrack.com/tests/login/crosshost/protected/ https://www.httrack.com/tests/login/crosshost/protected/ Case 3, a login only a browser can complete: https://www.httrack.com/tests/login/js/ https://www.httrack.com/tests/login/js/protected/ The accept URL takes a trailing slash. It is only ever reached from the case 2 redirect, which uses that form. Markers ------- Each protected page carries one marker, so a test can grep the mirrored output. LOGIN-OK basic /tests/login/basic/protected/ DEEP-OK basic-1 .../protected/deep1.php DEEP-OK basic-2 .../protected/deep2.php DEEP-OK basic-3 .../protected/deep3.php LOGIN-OK crosshost httrack.com/tests/login/crosshost/protected/ LOGIN-OK crosshost-www www.httrack.com/tests/login/crosshost/protected/ LOGIN-OK js /tests/login/js/protected/ LOGIN-REQUIRED any protected page without its cookie, with a 403 REJECTED-RAW-PASSWORD case 3, when a request posts the password itself REJECTED-NO-TOKEN case 3, when a request carries no valid token "LOGIN-OK basic" appears on one page only. The deeper pages use their own marker word so a grep for the login marker is not ambiguous. Cookies ------- whtt_session case 1. HttpOnly, Path=/tests/login/, no Expires. Gates case 1 on its own, so a harvest that drops HttpOnly cookies fails instead of passing quietly. whtt_persistent case 1. Path=/tests/login/, Expires one year out. whtt_awkward case 1. Value "a=1, b=2" including the quotes, so a comma and an equals sign have to survive the file writer. whtt_bare case 2. Host-only for httrack.com, no Domain attribute. whtt_www case 2. Host-only for www.httrack.com. whtt_js case 3. Every page prints a table of which of these the request carried, so a partial harvest is visible rather than just a failure. Each login page has a "Clear the cookies" link, which makes the fixture re-testable by hand. Case 2 clears one host at a time. Notes ----- The pages carry and an X-Robots-Tag header with "noindex, nofollow, noarchive". "nofollow" is deliberately absent from the meta tag, because the engine honours it there and would stop following the fixture's own links. Cases 1 and 2 need those links. The engine does not read the header, so real crawlers still get the full directive. For the same reason there is no robots.txt rule for /tests/. The engine honours robots.txt by default, so a Disallow would block the fixture from crawling itself. The pages carry no site navigation on purpose, so a test mirror stays small instead of pulling in the rest of the site. Case 2 needs an engine whose cookie matching honours host-only cookies. Older engines sent a cookie stored for httrack.com to www.httrack.com as well. Case 2 then passes even when the harvest took only the start host's cookies, and that is the one thing the case exists to catch. The version string does not tell you which engine you have, because master still reads 3.50-5 while carrying the change. Grep src/htsbauth.c for cookie_is_host_only() instead. The RFC 6265 grammar for a cookie value excludes a comma and a space even inside quotes, so whtt_awkward is strictly outside it. Browsers store and return it verbatim, which is what makes it a useful round-trip test.