Annotation of libwww/Library/src/HTAAUtil.html, revision 2.38
2.2 timbl 1: <HTML>
2.1 luotonen 2: <HEAD>
2.35 frystyk 3: <TITLE>W3C Sample Code Library libwww Access Authentication</TITLE>
2.13 frystyk 4: </HEAD>
2.1 luotonen 5: <BODY>
2.31 frystyk 6: <H1>
7: Access Authentication Manager
8: </H1>
2.13 frystyk 9: <PRE>
10: /*
2.18 frystyk 11: ** (c) COPYRIGHT MIT 1995.
2.13 frystyk 12: ** Please first read the full copyright statement in the file COPYRIGH.
13: */
14: </PRE>
2.31 frystyk 15: <P>
16: The <I>Authentication Manager</I> is a registry for <I>Authentication
17: Schemes</I> that follow the generic syntax defined by the
18: <A HREF="../../Protocols/">HTTP</A> <CODE>WWW-authenticate</CODE> and
19: <CODE>Authorization</CODE> headers. Currently, the only scheme defined is
20: <I>Basic Authentication</I>, but <I>Digest Authentication </I>will soon follow.
21: All <I>Authentication Schemes</I> are registered at run-time in form of an
22: <I>Authentication Module</I>. An <I>Authentication Module</I> consists of
23: the following:
24: <DL>
25: <DT>
26: <B>scheme</B>
27: <DD>
28: The name which is used to identify the scheme. This is equivalent to the
29: <CODE><scheme></CODE> part of the <CODE>WWW-authenticate</CODE> HTTP
30: header, for example "basic"
31: <DT>
32: <B>BEFORE Filter</B>
33: <DD>
34: When a new request is issued, the <I>Authentication Manage</I>r looks in
35: the URL tree to see if we have any access authentication information for
36: this particular request. The search is based on the realm (if known) in which
37: the request belongs and the URL itself. If a record is found then the
38: <I>Authentication Manager</I> calls the <I>Authentication Module</I> in order
39: to generate the credentials.
40: <DT>
41: <B>AFTER Filter</B>
42: <DD>
43: After a request has terminated and the result was lack of credentials, the
44: request should normally be repeated with a new set of credentials. The AFTER
45: filter is responsible for extracting the challenge from the HTTP response
46: and store it in the URL tree, so that we next time we request the same URL
47: we know that it is protected and we can ask the user for the appropriate
48: credentials (user name and password, for example).
49: <DT>
50: <B>garbage collection</B>
51: <DD>
52: The authentication information is stored in a <A HREF="HTUTree.html">URL
53: Tree</A> but as it doesn't know the format of the scheme specific parts,
54: you must register a garbage collector (gc). The gc is called when node is
55: deleted in the tree.
56: </DL>
57: <P>
58: <B>Note: </B>The <I>Authentication Manager</I> itself consists of
59: <B>BEFORE</B> and an <B>AFTER</B> <A HREF="HTFilter.html">filter</A> - just
60: like the <I>Authentication Modules</I>. This means that any <I>Authentication
61: Module</I> also can be registered directly as a <B>BEFORE</B> and
62: <B>AFTER</B> <A HREF="HTFilter.html">filter</A> by the <A HREF="HTNet.html">Net
63: Manager</A>. The reason for having the two layer model is that the
64: <I>Authentication Manager</I> maintains a single <A HREF="HTUTree.html">URL
65: tree</A> for storing access information for all <I>Authentication Schemes</I>.
66: <P>
67: An <I>Authentication Module</I> has three resources, it can use when creating
68: challenges or credentials:
69: <UL>
70: <LI>
71: Handle the <I>credentials</I> which is a part of the
72: <A HREF="HTReq.html#Access">Request obejct</A>. The credentials are often
73: generated by asking the user for a user name ansd a password.
74: <LI>
75: Handle the <I>challenges</I> which is a part of the
76: <A HREF="HTReq.html#Access">Request object</A>. The <A HREF="HTMIME.html">MIME
77: parser</A> will normally find the credentials as we parse the HTTP response.
78: <LI>
79: Add information to the <A HREF="HTUTree.html">URL Tree</A>
80: </UL>
81: <P>
82: This module is implemented by <A HREF="HTAAUtil.c">HTAAUtil.c</A>, and it
2.36 frystyk 83: is a part of the <A HREF="http://www.w3.org/Library/"> W3C Sample Code
2.31 frystyk 84: Library</A>.
2.1 luotonen 85: <PRE>
86: #ifndef HTAAUTIL_H
87: #define HTAAUTIL_H
2.23 frystyk 88: #include "HTReq.h"
2.31 frystyk 89: #include "HTNet.h"
90: #include "HTUTree.h"
2.15 frystyk 91: </PRE>
2.31 frystyk 92: <H2>
93: Authentication Scheme Registration
94: </H2>
95: <P>
96: An <I>Authentication Scheme</I> is registered by registering an
97: <I>Authentication Module</I> to in the <I>Authentication Manager</I>.
98: <H3>
99: Add an Authentication Module
100: </H3>
101: <P>
102: You can add an authentication scheme by using the following method. Each
103: of the callback function must have the type as defined below.
104: <PRE>
105: typedef struct _HTAAModule HTAAModule;
106:
107: extern HTAAModule * HTAA_newModule (const char * scheme,
2.34 frystyk 108: HTNetBefore * before,
109: HTNetAfter * after,
2.38 ! kahan 110: HTNetAfter * update,
2.31 frystyk 111: HTUTree_gc * gc);
112: </PRE>
113: <H3>
114: Find an Authentication Module
115: </H3>
116: <PRE>extern HTAAModule * HTAA_findModule (const char * scheme);
117: </PRE>
118: <H3>
119: Delete an Authentication Module
120: </H3>
121: <PRE>extern BOOL HTAA_deleteModule (const char * scheme);
122: </PRE>
123: <H3>
124: Delete ALL Authentication modules
125: </H3>
126: <PRE>extern BOOL HTAA_deleteAllModules (void);
127: </PRE>
128: <H2>
129: Handling the URL Tree
130: </H2>
131: <P>
132: The authentication information is stored as <A HREF="HTUTree.html">URL
133: Trees</A>. The root of a URL Tree is identified by a <I>hostname</I>
134: and a <I>port number</I>. Each URL Tree contains a set of templates and realms
135: which can be used to predict what information to use in a hierarchical tree.
136: <P>
137: The URL trees are automatically collected after some time so the application
138: does not have to worry about freeing the trees. When a node in a tree is
139: freed, the gc registered as part of the Authentication Module is called.
140: <P>
141: Server applications can have different authentication setups for each hostname
142: and port number, they control. For example, a server with interfaces
143: "<CODE>www.foo.com</CODE>" and "<CODE>internal.foo.com</CODE>" can have different
2.25 frystyk 144: protection setups for each interface.
2.31 frystyk 145: <H3>
2.37 frystyk 146: Add new or Update a Note in the UTree
2.31 frystyk 147: </H3>
148: <P>
2.32 frystyk 149: Add an access authentication information node to the database or update an
150: existing one. If the entry is already found then it is replaced with the
151: new one. The template must follow normal URI syntax but can include a wildcard
152: Return YES if added (or replaced), else NO
2.33 frystyk 153: <PRE>extern void * HTAA_updateNode (BOOL proxy,
154: char const * scheme,
2.32 frystyk 155: const char * realm, const char * url,
156: void * context);
2.31 frystyk 157: </PRE>
2.37 frystyk 158: <H3>
159: Delete a Node from the UTree
160: </H3>
161: <P>
162: This is called if an already entered node has to be deleted, for example
163: if it is not used (the user cancelled entering a username and password),
164: or for some reason has expired.
165: <PRE>extern BOOL HTAA_deleteNode (BOOL proxy_access, char const * scheme,
166: const char * realm, const char * url);
167: </PRE>
2.31 frystyk 168: <H2>
169: The Authentication Manager Filters
170: </H2>
171: <P>
172: As mentioned, the <I>Access Authentication Manager</I> is itself a set of
173: <A HREF="HTFilter.html">filters</A> that can be registered by the
174: <A HREF="HTNet.html">Net manager</A>.
2.32 frystyk 175: <H3>
176: Before Filter
177: </H3>
178: <P>
179: Make a lookup in the URL tree to find any context for this node, If no context
180: is found then we assume that we don't know anything about this URL and hence
181: we don't call any <I>BEFORE</I> filters at all.
2.34 frystyk 182: <PRE>
183: HTNetBefore HTAA_beforeFilter;
2.28 eric 184: </PRE>
2.32 frystyk 185: <H3>
186: After Filter
187: </H3>
188: <P>
189: Call the <I>AFTER</I> filter that knows how to handle this scheme.
2.34 frystyk 190: <PRE>
191: HTNetAfter HTAA_afterFilter;
2.1 luotonen 192: </PRE>
2.33 frystyk 193: <H3>
2.38 ! kahan 194: Update Filter
! 195: </H3>
! 196: <P>
! 197: Call the <I>UPDATE</I> filter that knows how to handle this scheme.
! 198: <PRE>
! 199: HTNetAfter HTAA_updateFilter;
! 200: </PRE>
! 201: <H3>
2.33 frystyk 202: Proxy Authentication Filter
203: </H3>
204: <P>
205: Just as for normal authentication we have a filter for proxy authentication.
206: The proxy authentication uses exactly the same code as normal authentication
207: but it stores the information in a separate proxy authentication
208: <A HREF="HTUTree.html">URL tree</A>. That way, we don't get any clashes between
209: a server acting as a proxy and a normal server at the same time on the same
210: port. The difference is that we only have a ingoing filter (a before filter)
211: as the out going filter is identical to the normal authentication filter.
212: The filter requires to be called after a proxy filter as we otherwise don't
213: know whether we are using a proxy or not.
214: <PRE>
2.34 frystyk 215: HTNetBefore HTAA_proxyBeforeFilter;
2.33 frystyk 216: </PRE>
2.1 luotonen 217: <PRE>
218: #endif /* NOT HTAAUTIL_H */
2.25 frystyk 219: </PRE>
2.31 frystyk 220: <P>
221: <HR>
2.30 frystyk 222: <ADDRESS>
2.38 ! kahan 223: @(#) $Id: HTAAUtil.html,v 1.2 1998/09/11 08:29:06 cvs Exp $
2.30 frystyk 224: </ADDRESS>
2.31 frystyk 225: </BODY></HTML>
Webmaster