M1606: Implementing HTTP authorization UI and persistent sessions: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
mNo edit summary
Line 29: Line 29:
4) In <code>modify_request_headers</code> in <code>http_loader.rs</code>, implemented the remaining pieces of step 12 of the [https://fetch.spec.whatwg.org/#http-network-or-cache-fetch appropriate specification ] using the authorization cache.
4) In <code>modify_request_headers</code> in <code>http_loader.rs</code>, implemented the remaining pieces of step 12 of the [https://fetch.spec.whatwg.org/#http-network-or-cache-fetch appropriate specification ] using the authorization cache.


'''A Wiki Page regarding this work can be found [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2016_OSS_M1606 here ] .
'''A Wiki Page regarding this work can be found [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2016_OSS_M1606 here ]
'''
'''


Line 43: Line 43:


4)
4)
== '''Design Patterns''' ==
The team was not given much freedom for design patterns.  We followed and used the existing servo design strategy.  You can read about the servo design [https://github.com/servo/servo/wiki/Design here]


== '''Implementation / Design Decisions''' ==
== '''Implementation / Design Decisions''' ==
Line 64: Line 67:
Objective:
Objective:


=='''Testing the new command line flag --profile-dir'''==
=='''Testing'''==
 
    git clone https://github.com/servo/servo.git
 
    cd servo
 
    ./mach build --dev
 
    ./mach run tests/html/about-mozilla.html --profile-dir [directory name]
 
    //A new folder should be created if it does not exist with the directory name
 
== '''Unit Test for set authorization header if url does not have credentials''' ==
The project maintainer instructed us to add one unit test to test the initial step functionality.  We have added a unit test to test that the authentication header is being set if credentials are contained in the cache
 
It can be run with the other unit tests with the command
 
    ./mach test-unit -p net
 
The unit test can be found in /servo/tests/unit/net/http_loader.rs
 
== '''GUI test for the tinyfiledialogs lib'''==
In addition to creating the rust FFI bindings for the tinyfiledialog C library our team also created a example rust program to test the new rust library.
 
To run the example and see all of the tinyfiledialog windows do the following.


    Git clone https://github.com/jdm/tinyfiledialogs.git
===Testing the new command line flag --profile-dir===


    cd tinyfiledialogs/examples/tinytest
'''[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2016_OSS_M1606#Testing_the_new_command_line_flag_--profile-dir Testing the new command line flag --profile-dir]'''


    cargo run
=== Unit Test for set authorization header if url does not have credentials ===


This will run tinytest which is a rust program that show cases the different GUI windows that the new rust tinyfiledialogs library has.
'''[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2016_OSS_M1606#Unit_Test_for_set_authorization_header_if_url_does_not_have_credentials Unit Test for set authorization header if url does not have credentials]'''
=== GUI test for the tinyfiledialogs lib===


== '''Design Patterns''' ==
'''[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2016_OSS_M1606#GUI_test_for_the_tinyfiledialogs_lib GUI test for the tinyfiledialogs lib]'''
The team was not given much freedom for design patterns.  We followed and used the existing servo design strategy.  You can read about the servo design [https://github.com/servo/servo/wiki/Design here]


== '''Conclusion''' ==
== '''Conclusion''' ==

Revision as of 17:33, 4 April 2016

M1606: Implementing HTTP authorization UI and persistent sessions

Web pages make use of sessions all the time. These are required to persist throughout the life of the user's interaction with the web site or web application.This is supported by Servo as of today. However it doesn't support the persistence of data upon the closing and reopening of the web browser.<ref> https://github.com/servo/servo/wiki/Persistent-sessions-student-project</ref>

With this project we aim to create the necessary infrastructure to support this.

Introduction

Servo

Servo is a web browser layout engine written in Rust and is currently being developed by Mozilla Research. The aim of the project is not to create a full browser but is rather to create a highly parallel environment that allows for many components be handled by fine-grained, isolated tasks. Servo is built on top of Rust to provide a secure and reliable foundation and is focused on creating a reliable and fast browser engine.<ref>https://en.wikipedia.org/wiki/Servo_(layout_engine)</ref>

Rust

Rust is a multi-paradigm, compiled programming language that is a good language for creating highly safe systems. Rust and Servo have a symbiotic relationship as the development of servo has influenced the design of the language. Rust is a modern, fast, memory safe and multithreaded programming language that focuses on speed and safety for developing reliable and efficient systems. It eliminates all data races by having numerous compile-time safety checks that adds no runtime overhead.<ref>https://en.wikipedia.org/wiki/Rust_(programming_language)</ref>

Previous Work

1) Added a new command line flag --profile-dir [path] that stores an optional directory path in the Opts struct in opts.rs, creates the directory if it does not exist.

2) Created Rust FFI bindings for the tinyfiledialogs library to allow calling the C methods from Servo.

3) In resource_thread.rs, defined an HTTP authorization cache storage (username, password, URL) and instantiated it like the cookie_storage member (inside an Arc<Rwlock<>> value, to enable sharing it between threads).

4) In modify_request_headers in http_loader.rs, implemented the remaining pieces of step 12 of the appropriate specification using the authorization cache.

A Wiki Page regarding this work can be found here

Scope

The scope of this project is to:

1)

2)

3)

4)

Design Patterns

The team was not given much freedom for design patterns. We followed and used the existing servo design strategy. You can read about the servo design here

Implementation / Design Decisions

Here are some of the design decisions that we have made for implementing the steps mentioned in Scope :

Step 1

Objective:

Step 2

Objective:

Step 3

Objective:

Step 4

Objective:

Testing

Testing the new command line flag --profile-dir

Testing the new command line flag --profile-dir

Unit Test for set authorization header if url does not have credentials

Unit Test for set authorization header if url does not have credentials

GUI test for the tinyfiledialogs lib

GUI test for the tinyfiledialogs lib

Conclusion

References

<references/>