Differences

This shows you the differences between two versions of the page.

--- findme:start [2009/12/11 01:47]
heedu
+++ findme:start [2009/12/21 15:56] (current)
syang26
@@ Line 1: / Line 1: @@
-====== Accessing file (11/25/09) ======
+====== Final Parser Upload (12/20/09) ======
+Here are the two late uploads of the .h and .m file for the parser.
+The last portion of the .m file shows how we store and separate each date and amounts of expenses endowments to different mutable arrays.
+{{:findme:parserimage1.png}}
+{{:findme:parserimage2.png}}
+{{:findme:parserimage3.png}}
+{{:findme:parserimage4.png}}
+{{:findme:parserimage5.png}}
+The following are the results printed to NSLog from the parser:
+{{:findme:parserimage6.png}}
+{{:findme:parserimage7.png}}
+{{:findme:parserimage8.png}}
+====== Accessing file (12/10/09) ======
+We tried to verify the webpage by using Objective-C methods like NSURLCredential, but we failed to access the webpage.
+Next, we tried to send Id and password through Post method in NSURLConnection class, but we also failed.
+So, we sent e-mail to cs lab and get information about cs authentication system.
+We heard about public cookie and get useful link.
+http://www.pubcookie.org/
+In those pages, we get steps to use public cookie.
+Components & Roles
+The Pubcookie model of user authentication is based on: a User-Agent, Pubcookie's two server components, and an external authentication service. Servers are classified as "login" or "application" servers. Examples of external authentication services include Kerberos, LDAP, and NIS. The User-Agent is most often represented by a user's web browser.
+The role of the Pubcookie login server is that of the trusted, central authentication service. It interacts directly with users. It verifies usernames and passwords with backend authentication services. It issues cookies to users to provide single sign-on functionality and to application servers to provide authentication information.
+The role of the Pubcookie application server is that of authentication enforcer. It redirects users who haven't been authenticated to the login server. It verifies authentication information returned from the login server. It issues cookies to users to maintain authenticated application sessions and provides user authentication information to applications.
+The role of the external authentication service is to verify user authentication information sent to it from the login server.
+The role of the User-Agent in all of this is simply to play along: to carry the user to the login server when redirected to do so, to assist the user by rendering the HTML-based user interface of the login server, and to accept all valid cookies set by the login and application servers.
+Setup & Configuration
+Pubcookie-based authentication begins with the setup and configuration of a Pubcookie login server and at least one Pubcookie application server that hosts at least one Pubcookie-protected application.
+During the setup phase, the login server and application server negotiate a shared, symmetric key, and the login server's public key is copied to the application server. Additionally, each application server is configured with the location of its login server and other site-specific details.
+The User-Agent requires no setup. Standard browser configurations work well.
+Initial Sign-on Process
+The intial sign-on process (i.e. how a user is initially authenticated) is illustrated in the following diagram; each step is explained in detail below the diagram. Redirection between servers is represented with dashed horizontal lines.
+A user makes a request to an application server for a resource (a URL) tied to an application that uses Pubcookie for authentication.
+The Pubcookie module intercepts the request and inspects it to determine that the request is not associated with a valid, existing authenticated session for the application and does not carry information from the login server (known as a "granting cookie", see steps 8 and 9) necessary to establish a new session.The Pubcookie module generates a response, including a "redirect" page and two cookies: a "pre-session" cookie scoped to the application, and a "granting request" cookie scoped to reach the login server. Both cookies contain, among other things, a random number generated by the Pubcookie module.
+The "redirect" page causes the user's browser to make a request to the Pubcookie login server, including the "granting request" cookie.This is the "granting request". It contains information about the application server, the original resource (URL), the desired type of authentication, etc.
+The Pubcookie login server decodes the "granting request" cookie and interprets the contents. In response, it generates a login form page and sends it to the browser, prompting the user to enter username and password.
+The user enters his or her username and password into the form and submits it, causing the browser to send the data to the login server.
+The Pubcookie login server takes the username and password and sends them to its backend authentication service for verification.
+The Pubcookie server receives the verification response.
+If verification is successful, the Pubcookie login server generates a response, including a "redirect" page and two new cookies. (If verification fails, another login form page is sent to the user's browser.) One cookie, known as the "granting cookie", contains the authenticated username and some other items, including the random number it received from the application server via the "granting request". The "granting coookie" is protected from tampering by being signed using the private key of the login server, and protected from disclosure by being encrypted using the symmetric key shared by the application server and the login server. It is scoped to reach the application server. The second cookie, known as the "login cookie", is scoped to the login server and will be used on any subsequent visits by the user to the login server.
+The "redirect" page causes the user's browser to re-request the original resource (URL) on the application server. This request contains the granting cookie set by the login server and the "pre-session" cookie set earlier by the application server.
+The Pubcookie module on the application server again intercepts the request, as in step 2. This time it finds the "granting cookie" which it decrypts using the shared symmetric key. It then verifies the signature using the login server's public key and matches the random number found in the "granting cookie" with the random number found in the "pre-session" cookie. If verification succeeds, the Pubcookie module supplies the authenticated username to the application along with the rest of the original request. It also generates a valid "session cookie" for subsequent requests by the user to the application. Having successfully authenticated the user, the application can finally send the original resource to the user. The Pubcookie module makes sure that the application's response is accompanied by the new "session cookie".
+Single Sign-on
+If, in step 4, the "granting request" is accompanied by a previously established, valid "login cookie" (as set in step 8), then steps 5, 6, and 7 are skipped, and the login server proceeds to step 8, issuing a "granting cookie" using the username as found in the "login cookie". This provides the "single sign-on" experience for the user, allowing him or her to request resources tied to other Pubcookie-authenticated resources without having to re-enter a password as long as the "login cooke" is still valid (e.g. for 8 hours after the intial sign-on).
+Logging Out
+A user's best, most effective method of logging out supercedes that which is provided by Pubcookie itself. Specifically, if a user quits his or her User-Agent or logs out of his or her operating system, all open sessions maintained by Pubcookie will be closed. The underlying assumption is that these user-driven events always clear the cookies that Pubcookie uses to maintain state. However, on some platforms and in some circumstances (see known problems) this assumption is not valid, and other means of logging out must be made.
+Pubcookie supports its own logout functionality too. Each application can configure a specific resource (URL) that, when requested by a user, will clear the application's current "session" cookie. Each application can also configure how it wants to respond to such logout requests. It can produce its own response or it can redirect the user to the login server which will generate a custom logout message on the application's behalf. The latter method provides better consistency among applications and a single point of convergence, at the login server, for other edifying messages, such as the state of the user's single sign-on session with the login service itself.
+Therefore, Pubcookie's logout functionality works on a "per-application" basis not a comprehensive "global" basis. Using this method, a user must manually log out of each application plus the login server. It's much simpler to quit the browser.
+Key Management
+Pubcookie's security model accounts for certain kinds of "man in the middle" attacks. In order to do so, it uses a shared symmetric key to encrypt certain messages sent between each application server and the login server.
+New keys are generated by the Pubcookie "keyserver" application running on a site's login server. They are negotiated and distrubuted using the Pubcookie "keyclient" utility during the setup phase of each application server. Keys are then maintained by the Pubcookie "keyserver" application running on a site's login server. Keys can be revoked at the login server, but automated expiration and renewal processes are not yet provided.
+We are going to implement verification using public cookie in above procedures.
+====== Accessing file (12/08/09) ======
+We can select cell in table and get file title.
+This delegate method will send httpRequest to get file contents.
+Here is delegate method.
+- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath {
+        // this line to get selected cell by user
+	HistoryCell *cell = (HistoryCell *)[table cellForRowAtIndexPath:indexPath];
+        // get contents of the cell
+        History *hs = cell.historyView.history;
+        // set a new url path to get contents of the file
+ 	NSString *path = hs.string;
+	NSString *newUrl = [[NSString alloc] init];
+	newUrl = [self.baseUrl stringByAppendingString:path];
+	HTTPRequest *httpRequest = [[HTTPRequest alloc] init];
+    [httpRequest setDelegate:self selector:@selector(didReceiveFinished:)];
+    // this line will try to connect to new url. After this line, methods we uploaded in 11/25/09 will execute.
+    [httpRequest requestUrl:newUrl];
+}
+I checked result in Debug console.
+{{:findme:fiile_contents.jpg|}}
+This is the contents of the .csv file.
+After this, we will implement authentication using public cookie.
+====== Accessing file (12/04/09) ======
+We tried to parse webpage efficiently, but we cannot find good way which use classes in Objective-C. So, we tried to
+study html in given webpage.
+''Code Text''
+// Http body
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
+<html>
+ <head>
+  <title>Index of /iphone-project</title>
+ </head>
+ <body>
+<h1>Index of /iphone-project</h1>
+<table><tr><th><img src="/icons/blank.gif" alt="[ICO]"></th><th><a href="?C=N;O=D">Name</a></th><th><a href="?C=M;O=A">Last modified</a></th><th><a href="?C=S;O=A">Size</a></th><th><a href="?C=D;O=A">Description</a></th></tr><tr><th colspan="5"><hr></th></tr>
+<tr><td valign="top"><img src="/icons/back.gif" alt="[DIR]"></td><td><a href="/">Parent Directory</a>       </td><td>&nbsp;</td><td align="right">  - </td></tr>
+<tr><td valign="top"><img src="/icons/unknown.gif" alt="[   ]"></td><td><a href="sample-xls-file.csv">sample-xls-file.csv</a>    </td><td align="right">24-Sep-2009 16:54  </td><td align="right"> 63K</td></tr>
+<tr><td valign="top"><img src="/icons/unknown.gif" alt="[   ]"></td><td><a href="sample-xls-file.xls">sample-xls-file.xls</a>    </td><td align="right">14-Sep-2009 23:40  </td><td align="right">276K</td></tr>
+<tr><th colspan="5"><hr></th></tr>
+</table>
+</body></html>
+}
+- This is the webpage showing file and directory lists. We found that "alt" variable determines type of the object. So,
+based on this http source, we made parsing method.
+Here is method.
+- (void) getFileNames:(NSString *)body {
+        // body means above http body.
+	const char *httpbody = [body UTF8String];
+	char tmpPath[100];
+	NSString *path;
+	BOOL check = NO;
+	BOOL find = NO;
+        //check all characters and get string we wanted.
+        //only [DIR] or [   ] is acceptable to show lists.
+	for ( int i = 0 ; i < strlen(httpbody) ; i++ ) {
+		if ( httpbody[i] == '[' )
+			check = YES;
+		else if ( httpbody[i] == ']' ) {
+			check = NO;
+		}
+		else if ( check == YES ) {
+			if ( httpbody[i] == 'D' )
+				if ( httpbody[i+1] == 'I' )
+					if ( httpbody[i+2] == 'R' )
+						find = YES;
+			if ( httpbody[i] == ' ' )
+				if ( httpbody[i+1] == ' ' )
+					if ( httpbody[i+2] == ' ' )
+						find = YES;
+		}
+		else if ( find == YES && httpbody[i] == 'h' && httpbody[i+1] == 'r' && httpbody[i+2] == 'e' && httpbody[i+3] == 'f' ) {
+			while ( httpbody[i-1] != '>' )
+				i++;
+			int j = 0;
+			while ( httpbody[i] != '<' ) {
+				tmpPath[j] = httpbody[i];
+				i++, j++;
+			}
+			tmpPath[j] = '\0';
+                        // new path to get file contents
+			path = [[NSString alloc] initWithCString:tmpPath];
+			NSLog(@" pathsms : %@", path);
+                        // this is filter to only show .csv files
+			NSString *searchForMe = @".csv";
+			NSRange range = [path rangeOfString : searchForMe];
+			if ( range.location != NSNotFound ) {
+                                // History is class we made to show file title in table
+				History *hs = [[History alloc] init];
+				hs.string = path;
+				[self.historyList addObject:hs];
+				[hs.string release];
+				[hs release];
+			}
+			//[hs release];
+			//[table
+			find = NO;
+		}
+	}
+        // update table
+	[table reloadData];
+	if ( [self.historyList count] > 0 ) {
+		NSIndexPath *indexPath = [NSIndexPath indexPathForRow:[historyList count]-1 inSection:0];
+		[table scrollToRowAtIndexPath:indexPath atScrollPosition:UITableViewScrollPositionNone animated:YES];
+	}
+}
+Using this method, we can finally show lists. After this method..
+{{:findme:filelists.jpg|}}
+====== Accessing file (11/29/09) ======
 Using given webpage : "https://www.cs.wisc.edu/iphone-project/". Finally, we can get lists by connecting that page.
 First, we connected to this page by using NSURL classes. Iphone support http communication without web browser like

WiNGS Lab @ UW

User Tools

Site Tools

Differences

Page Tools