Free cookie software for linux

CookieSwap provides an extension that enables you to maintain numerous sets or profiles of cookies that you can quickly.
Main features:
- Changing your cookies/identity to web e-mail sites (like Yahoo, Gmail, Hotmail, etc) so that you can quickly look like different users. Nice if you maintain multiple accounts and are tired of logging out and then back in to switch accounts. Also nice if two people are using the same computer and want to switch between accounts quickly.
- Changing your cookies/identity to see how sites like Amazon and Google treat you differently depending on who you are. For example, if Amazon recognizes you as a returning shopper they give you a different looking page (and there were claims that they give you different prices also). Google has begun to use a feature called "Personalized Search", where they modify their search results based on your user identity. There is a question about this when you create your Google account. The results of Google searches are different depending on if Google knows you or not. Use CookieSwap to quickly swap between Google recognizing you and being anonymous. Run the same search and see the differences.
- If you design web sites, you can setup numerous cookie profiles to look like different types of users and swap between those users quickly and easily to test your site in numerous modes (you can hand edit the cookies to have distinct values in each profile using a nice extension like Add & Edit Cookies).

Permit Cookies is a Firefox extension that allows you to set cookie permissions for the site you are viewing. Suggested usage: Disable cookies in Tools-Options-Privacy and only permit cookies from sites you trust.

mod_auth_cookie_dbm is a session authentication/expiration using (cryptographically strong) cookies. Cookie-to-username mapping with DBM database.

It was devised as a better replacement for the "Basic" authentication components that ship with Apache.

Classic "Basic" authentication has some downsides:

- Username and password are shipped across the net with every request.
- There is no concept of a "session" (nor encores, such as timeouts and automatic logout)

This module

1. checks requests for a cookie, named in the CookieDBMAuthCookieName configuration directive.

2. If found, the cookie value is looked up in a DBM database, named in the CookieDBMAuthFile directive.
If the lookup fails, a redirect is made to a page specified in the CookieDBMAuthFailureURL directive.

3. The DBM entry is expected to contain a username and optionally an expiry time. Fields are colon-separated, the expiry time is a spelled-out integer (the field gets passed to strtol()) representing the time_t
If valid, the username is taped onto the request, thus "emulating" Basic authentication.
If expired, redirect to the CookieDBMAuthFailureURL.

The CookieDBMAuthFailureURL typically points at a "login page" CGI script. This program, after checking the users credentials, should make up a cookie value (preferably a long, cryptographically strong random string), enter it in the dbm file, and pass it to the browser. It might also update an AuthUserFile or AuthDBMUserFile database on the fly.

Acknowledgements:

This module was written from scratch, with some inspiration from the mod_auth_cookie_mysql and mod_auth_cookie_pgsql2 modules.

Apache2::AuthCookieDBI is an AuthCookie module backed by a DBI database.

SYNOPSIS

# In httpd.conf or .htaccess

PerlModule Apache2::AuthCookieDBI
PerlSetVar WhatEverPath /
PerlSetVar WhatEverLoginScript /login.pl

# Optional, to share tickets between servers.
PerlSetVar WhatEverDomain .domain.com

# These must be set
PerlSetVar WhatEverDBI_DSN "DBI:mysql:database=test"
PerlSetVar WhatEverDBI_SecretKey "489e5eaad8b3208f9ad8792ef4afca73598ae666b0206a9c92ac877e73ce835c"

# These are optional, the module sets sensible defaults.
PerlSetVar WhatEverDBI_User "nobody"
PerlSetVar WhatEverDBI_Password "password"
PerlSetVar WhatEverDBI_UsersTable "users"
PerlSetVar WhatEverDBI_UserField "user"
PerlSetVar WhatEverDBI_PasswordField "password"
PerlSetVar WhatEverDBI_CryptType "none"
PerlSetVar WhatEverDBI_GroupsTable "groups"
PerlSetVar WhatEverDBI_GroupField "grp"
PerlSetVar WhatEverDBI_GroupUserField "user"
PerlSetVar WhatEverDBI_EncryptionType "none"
PerlSetVar WhatEverDBI_SessionLifetime 00-24-00-00

# Protected by AuthCookieDBI.
< Directory /www/domain.com/authcookiedbi >
AuthType Apache2::AuthCookieDBI
AuthName WhatEver
PerlAuthenHandler Apache2::AuthCookieDBI->authenticate
PerlAuthzHandler Apache2::AuthCookieDBI->authorize
require valid-user
# or you can require users:
require user jacob
# You can optionally require groups.
require group system
< /Directory >

# Login location.
< Files LOGIN >
AuthType Apache2::AuthCookieDBI
AuthName WhatEver
SetHandler perl-script
PerlHandler Apache2::AuthCookieDBI->login
< /Files >

This module is an authentication handler that uses the basic mechanism provided by Apache2::AuthCookie with a DBI database for ticket-based protection. It is based on two tokens being provided, a username and password, which can be any strings (there are no illegal characters for either). The username is used to set the remote user as if Basic Authentication was used.

On an attempt to access a protected location without a valid cookie being provided, the module prints an HTML login form (produced by a CGI or any other handler; this can be a static file if you want to always send people to the same entry page when they log in). This login form has fields for username and password. On submitting it, the username and password are looked up in the DBI database. The supplied password is checked against the password in the database; the password in the database can be plaintext, or a crypt() or md5_hex() checksum of the password. If this succeeds, the user is issued a ticket. This ticket contains the username, an issue time, an expire time, and an MD5 checksum of those and a secret key for the server. It can optionally be encrypted before returning it to the client in the cookie; encryption is only useful for preventing the client from seeing the expire time. If you wish to protect passwords in transport, use an SSL-encrypted connection. The ticket is given in a cookie that the browser stores.

After a login the user is redirected to the location they originally wished to view (or to a fixed page if the login "script" was really a static file).
On this access and any subsequent attempt to access a protected document, the browser returns the ticket to the server. The server unencrypts it if encrypted tickets are enabled, then extracts the username, issue time, expire time and checksum. A new checksum is calculated of the username, issue time, expire time and the secret key again; if it agrees with the checksum that the client supplied, we know that the data has not been tampered with. We next check that the expire time has not passed. If not, the ticket is still good, so we set the username.

Authorization checks then check that any "require valid-user" or "require user jacob" settings are passed. Finally, if a "require group foo" directive was given, the module will look up the username in a groups database and check that the user is a member of one of the groups listed. If all these checks pass, the document requested is displayed.
If a ticket has expired or is otherwise invalid it is cleared in the browser and the login form is shown again.

Cookie Button in the status bar is a Firefox button for easy access to cookie permissions in the status bar. For those who have been asking for cookie button in the status bar.

Some features are optional. See Tools -> Extensions/Addons, select Cookie button in the status bar, press Options/Preference Button.

Please post more info about the context menu bug to http://bugzilla.mozdev.org/show_bug.cgi?id=15011

cosign is a Web single sign on system that allows users to authenticate once per session and access any protected Web resources at the institution. When you use cosign the passwords are sent only to a single, central URL.
Sessions have both idle and hard timeouts, and users can logout of all protected services by visiting a single URL. The use of public key cryptography ensures that a compromise of a protected Web server has no impact on the security of other participating servers.
cgi
The central cgi is responsible for logging users into and out of the central cosign server. It is also responsible for registering each service a user logs into - this action ties the users central login cookie to their session on individual application servers such as our web mail client, web directory client, or CourseTools environment. The prototype CGI was built to use Kerberos V/GSSAPI to authenticate the user.
daemon
The central daemon is responsible for maintaining the state of all cosign sessions. This includes keeping track of which users have logged in, logged out, and idle timed out. This also means the daemon keeps track of all of the service cookies that represent the authenticated web applications a user has accessed. The daemon has the ability to replicate its cookie database to multiply hosts, so a failure of one server does not constitute a failure of the system. The daemon answers queries of user identity from both the cgi and the filter, and talks to other daemons through a replication protocol. The daemon was written in C and has knowledge of Kerberos V tickets.
filter
The filter resides on an application server, and is not part of the centralized cosign infrastructure. The filter is responsible for determining which areas of a web site are protected by cosign and which are not. If a user attempts to access a protected area, the filter assures the user is authenticated, and obtains their username, authentication realm, IP address, and optionally a Kerberos ticket. This information can then be used by other authorization mechanisms to make further access decisions. The prototype filter was written in C for Apache 1.3.x.
Enhancements:
- daemon: updated return codes
- daemon: fixed bug in retrieve access control
- daemon: fixed bug where HUP with replication turned on would cause the server to die and exit.
- man: reorganized and fixed typos

PagePoker is a Perl package that defines a browser agent with many powerful features for monitoring and testing Web sites, including elaborate failure handling that can send email and trigger SNMP traps. The application comes with three scripts that implement it for different uses: poke.pl, for single agents; pokes.pl, for many parallel agents, and pokehard.pl, for loadtesting and benchmarking.

HOW-TO:

Run "poke.pl --help" for detailed help on using the package. Briefly, poke.pl creates a PagePoker object, accepting all sorts of options. It is designed for monitoring web pages to verify they are returning desired information or to dump the contents of web pages to a file (like fetch). It can loop on a variety of conditions and crawl a series of pages, posting and passing cookies. The other component, pokes.pl, is simply a forking variation that accepts as its parameters an agent id and the options for that agent. It can be used for monitoring many sites simultaneously or for load testing single sites. On a dual 400 mhz machine I was able to run about 120 concurrent agents.

Examples:

> poke.pl --url http://node.to

returns (first element is date):
20000225170507 SUCCESS: Page loaded by agent

> poke.pl --url http://node.to --no-status --print-response

returns the plain html

> pokes.pl agent1 "--url http://node.to --no-status --email-failures
--email-address who@node.to --iterations 1000 --interval 10"
agent2 "--urls http://node.to>>http://tiny.node.to
--no-status --email-failures --email-address "1@1.com 2@2.com""

will launch two agents, first agent will poll node.to for connection failures every 10 seconds 1000 times, emailing if a failure is encountered, second agent will hit node.to then tiny.node.to and exit, emailing two people if either one doesnt respond.

There is a lot of logic to control how often and under what conditions email is sent. You can search for desired in text the headers or the html response, and send email or snmp traps on certain failure conditions. To loadtest, you could launch looping batches of ten agents, adding ten more a minute later in a another process, etc.

More advanced load testing can be done with pokehard.pl. It gets its own README (README.pokehard).

Here is the output of poke.pl --help, minus the USAGE statement:

How to use it:

--url "http://host/page"

--urls "http://host/page1>>http://host/page2>>etc"

--urls-from-file "file_path"

--urls-delay "n"
Seconds between each request

--method {GET|POST}

--post-query "query string"

--basic-auth-name "agent login" (one per agent)

--basic-auth-pass "agent password"

--interval "n"
Loop with n seconds between pokes

--iterations "n"
Cycles to run loop (requires --interval)

--look-for "pattern to find in response text"

--resend-cookie "cookiename"

--resend-cookie-between-iterations
Allow cookie to be resent through all iterations

--use-verbose-response
Includes headers in response text

--print-response
Dump agent retrieved text to STDOUT

--disable-on-failure
Allow server disabling on failure

--disable-snmp-trap "snmp trap"
To disable in loadbalancer

--enable-on-recovery
Allow server re-enabling on recovery

--enable-snmp-trap "snmp trap"
To enable server after successful run

--email-failures
Turn on alarm emails

--email-addresses "address1 address2 etc"

--email-subject "override default with arbitrary text"

--failures-until-email "n"
Consecutive errors triggers email

--min-time-between-emails "seconds"

--die-after-date "yyyymmddhhmmss" (requires interval and iterations)

--benchmark
Store numbers used for performance measurement (by pokehard.pl)

--quiet
Output nothing (except email, if set)

--no-status
Do not output status info (ie SUCCESS, etc)

--print-to-file "file"
Write output to file

--help
Print this text and exit

Download Machine provides a noninteractive, nongraphical, pure Java batch file downloader.
Download Machine is pure Java daemon that watches queue files for changes. If a new entry is available, DM will download it. Queue files are just URL lists. DM fully supports the HTTP, FSP, and FTP protocols.
Main features:
- Design goals
- Non graphical
- Non interactive
- Relieable downloads
- Queued downloads
- Portability (uses Java)
- Simple to use
- Resume interrupted downloads
- Transports
- Support for HTTP/1.1 protocol
- Support for HTTP/1.0 protocol
- Support for FTP protocol
- Support for FSP protocol
- Custom headers
- Fake user-agent header
- Custom referer header, configurable per URL
- Custom cookie header, configurable per URL
- Other features
- Can check in different directories if we already have downloaded file (configurable by wildcard)
- Can move downloaded file to special directory (configurable by wildcard)