WiNGS Lab @ UW

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== 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 
safari in code. As I linked to apis in url loading system, There are delegate methods to connect to webpage. 
Here are codes:

- (BOOL)requestUrl:(NSString *)url 
{
    // first make request to send message to url 
    NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:url]
                                                           cachePolicy:NSURLRequestUseProtocolCachePolicy
                                                       timeoutInterval:5.0f];
	
    // using given url and request, try to connect
    NSURLConnection *connection = [[[NSURLConnection alloc] initWithRequest:request delegate:self] autorelease];
        
    // if connection is correct
    if(connection)
    {
        // initialize space which save data from response
        receivedData = [[NSMutableData alloc] init];
        return YES;
    }
	
    return NO;
}

Below methods are delegate methods. Those works during iphone tries to connect with specific url. 

- (void)connection:(NSURLConnection *)connection didReceiveResponse:(NSURLResponse *)aResponse
{
    //just save response 
    self.response = aResponse;
	NSArray *cookies;
}

This delegate method save data which is from web server.

- (void)connection:(NSURLConnection *)connection didReceiveData:(NSData *)data
{
	if ( data ) {
        // this method can be called several times when data are sent from server in pieces. 
		[receivedData appendData:data];
  
	}
}

This delegate method notify the situation when error occurs

- (void)connection:(NSURLConnection *)connection didFailWithError:(NSError *)error
{
    NSLog(@"Error: %@", [error localizedDescription]);
}

When transfer data from server to client, this method is called to deal with given data.

- (void)connectionDidFinishLoading:(NSURLConnection *)connection
{
    // convert data to NSString for convenience.
    result = [[NSString alloc] initWithData:receivedData encoding:NSUTF8StringEncoding];
    
    // send converted data to specific method which manipulates data.
    if(target)
    {
        [target performSelector:selector withObject:result];
    }
}

- (void)setDelegate:(id)aTarget selector:(SEL)aSelector
{
    // set selector which will be used after connection.
    self.target = aTarget;
    self.selector = aSelector;
}

After this methods, we can get information of webpage : "https://www.cs.wisc.edu/iphone-project/.
We will going to get parse data to get lists.

====== Accessing file (11/25/09) ======
Before authentication, we've tried to save file using given webpage : "https://www.cs.wisc.edu/iphone-project/
Of course, we have to access private webpage after verification. First, we wanted to implement download file. 
So, first we made temporary design and check result using debug console where programmer notify messages by using 
NSLOG method. 
{{:findme:firstdesign.jpg|}}
This is first one. This includes one table and three text boxes. 
User will insert id and password and url where .csv files are uploaded. 
After user push the button whose title is "Get Lists", table shows .csv and directories. 

====== Accessing file (11/16/09) ======
We've found a website for implementing url loading by using cookies.
Detail document is at this page.

http://developer.apple.com/iphone/library/documentation/Cocoa/Conceptual/URLLoadingSystem/URLLoadingSystem.html

We're going to find a way to access the cs server where we get a permission using cookie after identification.

====== Budget Chart (11/10/09) ======
{{:findme:graph.png|}} 

We've made a sample code to practice using core-plot libraries.
Below codes are core part of the sample source.

{{:findme:code1.png|}}
{{:findme:code2.png|}}
{{:findme:code3.png|}}

====== Budget Chart (11/08/09) ======
We've found a graphing library called core-plot. We should figure out managing this library. Detail document is at this website
[[http://code.google.com/p/core-plot/wiki/HighLevelDesignOverview|Core-Plot]]

====== Budget Chart (10/23/09) ======
I have found some interesting softwares relating to our project. Maybe we can use that to figure out what we should do with the graphical interface tomorrow when we meet.

====== Create QRcode (10/12/09) ======
We can create the QRcode from this website
[[http://qrcode.kaywa.com/|Kawa.com]]

1. As you can see below the image, you need to select "Content type" to "Text".

 Also, this QR code contains some information with typical format 

"Google calendar ID:Department:Name" Each information is separated by colon ":"

{{:findme:qrcode1.png|}}

2. This is an example of generating QR-code

{{:findme:qrcode2.png|}}




====== Screenshots of FindMe ======

1. This is the first starting screen of the application. The IPhone camera can be used to take a picture of the barcode or you have the option to choose from your saved files.

{{:findme:img_0474.png|}}

----



2. When the barcode gets decoded, the information decoded in the barcode pops up.

{{:findme:img_0475.png|}}

----




3. If you click "Open" button from step 2, the individual's one day's schedule will show up in the following format.

{{:findme:img_0476.png|}}

----




4. For more information about the schedule, one can click on the "Week" button to see the one week amount of schedule for this person.

{{:findme:img_0477.png|}}


----



5. hen the "E-Mail" button is clicked, the following pop up will show up. If you click ok, the current applcation will close down, and the IPhone's email application will run.

{{:findme:img_0478.png|}}


----



6. As shoon below, the email applcation will have the email address of the barcode's owner.

{{:findme:img_0479.png|}}
WiNGS Lab @ UW

User Tools

Site Tools

Page Tools
