https://wiki.expertiza.ncsu.edu/api.php?action=feedcontributions&feedformat=atom&user=Mverma4 2026-08-12T08:00:07Z User contributions MediaWiki 1.41.0 https://wiki.expertiza.ncsu.edu/index.php?title=M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions&diff=102309 2016-04-26T02:19:33Z

<p>Mverma4: /* Implementation / Design Decisions */</p> <hr /> <div>''' M1606: Implementing HTTP authorization UI and persistent sessions '''<br /> <br /> [https://en.wikipedia.org/wiki/Web_page Web pages] make use of [https://en.wikipedia.org/wiki/Session_(computer_science) 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.&lt;ref&gt; https://github.com/servo/servo/wiki/Persistent-sessions-student-project&lt;/ref&gt;<br /> <br /> With this project we have created the necessary infrastructure to support this.<br /> <br /> == '''Introduction''' ==<br /> <br /> <br /> === Servo ===<br /> <br /> <br /> [https://en.wikipedia.org/wiki/Servo_(layout_engine) 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.<br /> 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.&lt;ref&gt;https://en.wikipedia.org/wiki/Servo_(layout_engine)&lt;/ref&gt;<br /> <br /> === Rust ===<br /> <br /> [http://doc.rust-lang.org/book/README 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.<br /> 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.&lt;ref&gt;https://en.wikipedia.org/wiki/Rust_(programming_language)&lt;/ref&gt;<br /> <br /> == '''Previous Related Work''' ==<br /> <br /> '''A Wiki Page regarding this work can be found [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2016_OSS_M1606 here ]'''<br /> <br /> 1) Added a new command line flag &lt;code&gt; --profile-dir [path]&lt;/code&gt; that stores an optional directory path in the Opts struct in &lt;code&gt;opts.rs&lt;/code&gt;, creates the directory if it does not exist.<br /> <br /> <br /> 2) Created [http://doc.rust-lang.org/book/ffi.html Rust FFI bindings] for the &lt;code&gt;[https://github.com/jdm/tinyfiledialogs tinyfiledialogs] &lt;/code&gt;library to allow calling the C methods from Servo.<br /> <br /> <br /> 3) In &lt;code&gt;resource_thread.rs&lt;/code&gt;, defined an HTTP authorization cache storage (username, password, URL) and instantiated it like the cookie_storage member (inside an &lt;code&gt;Arc&lt;Rwlock&lt;&gt;&gt;&lt;/code&gt; value, to enable sharing it between threads).<br /> <br /> <br /> 4) In &lt;code&gt;modify_request_headers&lt;/code&gt; in &lt;code&gt;http_loader.rs&lt;/code&gt;, 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.<br /> <br /> ''' The Pull Requests for these steps can be found [http://wiki.expertiza.ncsu.edu/index.php/M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions#Initial_Steps_Pull_Requests here]'''<br /> <br /> == '''Scope''' ==<br /> The scope of the project comprises of the 4 steps listed below:<br /> <br /> 1) Ensure the appearance of an authorization UI in case a [https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html 401 HTTP response] is received. In load in the [https://github.com/servo/servo/blob/master/components/net/http_loader.rs http_loader.rs], immediately before attempting to process an HTTP redirection, the new [https://sourceforge.net/projects/tinyfiledialogs/ tinyfiledialogs] is made use of to make two prompts to pop up (for username and password), subsequently the request is restarted and the new authorization value present applied. If an authorization value was indeed present and the response is successful, the credentials are added to the authorization cache.<br /> <br /> 2) If the command-line option of the profile directory is present when the ResourceThread is instructed to exit, the data contained in the cookie_storage, hsts_list, and the new HTTP authorization cache is serialized. This serialized data is then written in separate files inside the profile directory.<br /> <br /> 3) Perform similar serialization upon shutdown for local_data in [https://doc.servo.org/src/net_traits/storage_thread.rs.html storage_thread.rs], which represents the LocalStorage API.<br /> <br /> 4) Check if the command-line option is present in the profile directory in the ResourceThreadconstructor and look for files that will contain serialized versions of the previous steps. If such files do exist, populate the appropriate fields with deserialized versions of the file’s contents.<br /> <br /> == '''Design Patterns''' ==<br /> 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]<br /> <br /> We do use a facade pattern by creating a safe RUST wrapper around the RUST FFI for the tinyfiledialogs library that we will use for the UI. We could have just called the FFI functions from servo, but instead we created a safe and simple interface to call the library functions.<br /> <br /> == '''Implementation / Design Decisions''' ==<br /> <br /> === Step 1 ===<br /> <br /> Objective: Make an authorization UI appear when a 401 HTTP response is received <br /> <br /> Using the tinyfiledialogs RUST FFI bindings that the team created in the initial steps we created a UI for the user to enter his username and password when a 401 request is received for a basic HTTP authentication. We then first check if the status code of the http response is &quot;unauthorized&quot;. If the code is unauthorized we then display the UI for the user to enter his username and password. After the username and password are entered the request is restarted with the authentication header added. If the request is successful we create a new authentication entry struct and place it into the Authentication hash map for future use.<br /> <br /> The UML Diagram for this implementation can be found [http://wiki.expertiza.ncsu.edu/index.php/M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions#UML_for_step_1 here]<br /> <br /> === Step 2 ===<br /> <br /> Objective: On shutdown serialize the data contained in cookie_storage, hsts_list, and the new HTTP authorization cache, and write the serialized data in separate files inside the profile directory.<br /> <br /> When a Resource Thread exits we check if the opts structure located in opts.rs contains an entry for the command line option &quot;--profile dir&quot;. If the option is present when the Resource Thread exits we open or create a file for each data set we are saving. After each file is opened or created we serialize the data that corresponds to that file with the rust serialize library and save the serialized data to the file.<br /> <br /> The UML Diagram for this implementation can be found [http://wiki.expertiza.ncsu.edu/index.php/M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions#UML_for_step_2 here]<br /> <br /> === Step 3 ===<br /> <br /> Objective: On shutdown serialize the local_data in storage_thread.r<br /> <br /> This is similar to step 2 and some code re-use is used. However, the difference between this step and step 2 is that the local data contained in storage_thread.rs is the data that is being serialized and saved into the same directory.<br /> <br /> === Step 4 ===<br /> <br /> Objective: If the command line option for profile-dir is present then load the serialized data present in the directory that is given.<br /> <br /> When a resource thread is created we check if the opts structure located in opts.rs contains a entry for the command line option &quot;--profile dir&quot;. If the option is present then the data from each file contained in the directory is opened and deserialized using the serialize rust library. The data is then be placed in the appropriate fields. i.e (cookie_storage, hsts_lists, authorization_cache)<br /> <br /> The UML Diagram for this implementation can be found [http://wiki.expertiza.ncsu.edu/index.php/M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions#UML_for_step_4 here]<br /> <br /> '''The Pull Requests for these steps can be found [http://wiki.expertiza.ncsu.edu/index.php/M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions#Subsequent_Steps_Pull_Requests here]'''<br /> <br /> =='''UML Diagrams'''==<br /> <br /> ==='''UML for step 1'''===<br /> <br /> [[File:517project.png ]]<br /> <br /> <br /> ==='''UML for step 2'''===<br /> <br /> [[File:STEP2.png ]]<br /> <br /> <br /> ==='''UML for step 4'''===<br /> <br /> [[File:STEP4.png ]]<br /> <br /> == '''Pull Requests''' ==<br /> All pull requests that fully implement the initial steps and the subsequent steps have been accepted by a servo maintainer and successfully merged to the servo master branch<br /> <br /> ==='''Initial Steps Pull Requests'''===<br /> <br /> These are the pull requests that complete the initial steps of the project:<br /> <br /> 1) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/servo/servo/pull/10087 Added a new command line flag --profile-dir ]&lt;/span&gt;<br /> <br /> 2) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/jdm/tinyfiledialogs/pull/1 Added Rust FFI bindings to lib.rs ]&lt;/span&gt;<br /> <br /> 3) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/servo/servo/pull/10111 Added authorization cache to resources &amp; set authorization header from it if url does not have credentials ]&lt;/span&gt;<br /> <br /> ==='''Subsequent Steps Pull Requests'''===<br /> <br /> These are the pull requests that complete the Final steps of the project:<br /> <br /> 1) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/servo/servo/pull/10328 401 authorization UI]&lt;/span&gt;<br /> <br /> 2) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/servo/servo/pull/10661 Writing the serialized data in separate files inside the profile directory]&lt;/span&gt;<br /> <br /> 3) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/servo/servo/pull/10800 Deserializing the data and populating the appropriate fields]&lt;/span&gt;<br /> <br /> <br /> =='''Testing'''==<br /> <br /> ==='''Testing the new command line flag --profile-dir'''===<br /> <br /> git clone https://github.com/servo/servo.git<br /> <br /> cd servo<br /> <br /> ./mach build --dev<br /> <br /> ./mach run tests/html/about-mozilla.html --profile-dir [directory name]<br /> <br /> //A new folder should be created if it does not exist with the directory name<br /> <br /> === '''Unit Test for set authorization header if url does not have credentials''' ===<br /> 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 <br /> <br /> It can be run with the other unit tests with the command <br /> <br /> ./mach test-unit -p net<br /> <br /> The unit test can be found in /servo/tests/unit/net/http_loader.rs<br /> <br /> === '''GUI test for the tinyfiledialogs lib'''===<br /> 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.<br /> <br /> To run the example and see all of the tinyfiledialog windows do the following.<br /> <br /> Git clone https://github.com/jdm/tinyfiledialogs.git<br /> <br /> cd tinyfiledialogs/examples/tinytest<br /> <br /> cargo run<br /> <br /> This will run tinytest which is a rust program that show cases the different GUI windows that the new rust tinyfiledialogs library has.<br /> <br /> =='''Conclusion'''==<br /> <br /> We have successfully completed all the steps mentioned in the [https://github.com/servo/servo/wiki/Persistent-sessions-student-project NCSU Student Projects Page]. All the Pull requests have been accepted and merged with the servo master branch. <br /> <br /> We have also created a [ Video] explaining our entire project<br /> <br /> =='''References'''==<br /> &lt;references/&gt;</div>

Mverma4 https://wiki.expertiza.ncsu.edu/index.php?title=M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions&diff=102308 2016-04-26T02:18:46Z

<p>Mverma4: /* Conclusion */</p> <hr /> <div>''' M1606: Implementing HTTP authorization UI and persistent sessions '''<br /> <br /> [https://en.wikipedia.org/wiki/Web_page Web pages] make use of [https://en.wikipedia.org/wiki/Session_(computer_science) 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.&lt;ref&gt; https://github.com/servo/servo/wiki/Persistent-sessions-student-project&lt;/ref&gt;<br /> <br /> With this project we have created the necessary infrastructure to support this.<br /> <br /> == '''Introduction''' ==<br /> <br /> <br /> === Servo ===<br /> <br /> <br /> [https://en.wikipedia.org/wiki/Servo_(layout_engine) 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.<br /> 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.&lt;ref&gt;https://en.wikipedia.org/wiki/Servo_(layout_engine)&lt;/ref&gt;<br /> <br /> === Rust ===<br /> <br /> [http://doc.rust-lang.org/book/README 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.<br /> 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.&lt;ref&gt;https://en.wikipedia.org/wiki/Rust_(programming_language)&lt;/ref&gt;<br /> <br /> == '''Previous Related Work''' ==<br /> <br /> '''A Wiki Page regarding this work can be found [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2016_OSS_M1606 here ]'''<br /> <br /> 1) Added a new command line flag &lt;code&gt; --profile-dir [path]&lt;/code&gt; that stores an optional directory path in the Opts struct in &lt;code&gt;opts.rs&lt;/code&gt;, creates the directory if it does not exist.<br /> <br /> <br /> 2) Created [http://doc.rust-lang.org/book/ffi.html Rust FFI bindings] for the &lt;code&gt;[https://github.com/jdm/tinyfiledialogs tinyfiledialogs] &lt;/code&gt;library to allow calling the C methods from Servo.<br /> <br /> <br /> 3) In &lt;code&gt;resource_thread.rs&lt;/code&gt;, defined an HTTP authorization cache storage (username, password, URL) and instantiated it like the cookie_storage member (inside an &lt;code&gt;Arc&lt;Rwlock&lt;&gt;&gt;&lt;/code&gt; value, to enable sharing it between threads).<br /> <br /> <br /> 4) In &lt;code&gt;modify_request_headers&lt;/code&gt; in &lt;code&gt;http_loader.rs&lt;/code&gt;, 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.<br /> <br /> ''' The Pull Requests for these steps can be found [http://wiki.expertiza.ncsu.edu/index.php/M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions#Initial_Steps_Pull_Requests here]'''<br /> <br /> == '''Scope''' ==<br /> The scope of the project comprises of the 4 steps listed below:<br /> <br /> 1) Ensure the appearance of an authorization UI in case a [https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html 401 HTTP response] is received. In load in the [https://github.com/servo/servo/blob/master/components/net/http_loader.rs http_loader.rs], immediately before attempting to process an HTTP redirection, the new [https://sourceforge.net/projects/tinyfiledialogs/ tinyfiledialogs] is made use of to make two prompts to pop up (for username and password), subsequently the request is restarted and the new authorization value present applied. If an authorization value was indeed present and the response is successful, the credentials are added to the authorization cache.<br /> <br /> 2) If the command-line option of the profile directory is present when the ResourceThread is instructed to exit, the data contained in the cookie_storage, hsts_list, and the new HTTP authorization cache is serialized. This serialized data is then written in separate files inside the profile directory.<br /> <br /> 3) Perform similar serialization upon shutdown for local_data in [https://doc.servo.org/src/net_traits/storage_thread.rs.html storage_thread.rs], which represents the LocalStorage API.<br /> <br /> 4) Check if the command-line option is present in the profile directory in the ResourceThreadconstructor and look for files that will contain serialized versions of the previous steps. If such files do exist, populate the appropriate fields with deserialized versions of the file’s contents.<br /> <br /> == '''Design Patterns''' ==<br /> 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]<br /> <br /> We do use a facade pattern by creating a safe RUST wrapper around the RUST FFI for the tinyfiledialogs library that we will use for the UI. We could have just called the FFI functions from servo, but instead we created a safe and simple interface to call the library functions.<br /> <br /> == '''Implementation / Design Decisions''' ==<br /> <br /> === Step 1 ===<br /> <br /> Objective: Make an authorization UI appear when a 401 HTTP response is received <br /> <br /> Using the tinyfiledialogs RUST FFI bindings that the team created in the initial steps we created a UI for the user to enter his username and password when a 401 request is received for a basic HTTP authentication. We then first check if the status code of the http response is &quot;unauthorized&quot;. If the code is unauthorized we then display the UI for the user to enter his username and password. After the username and password are entered the request is restarted with the authentication header added. If the request is successful we create a new authentication entry struct and place it into the Authentication hash map for future use.<br /> <br /> The UML Diagram for this implementation can be found [http://wiki.expertiza.ncsu.edu/index.php/M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions#UML_for_step_1 here]<br /> <br /> === Step 2 ===<br /> <br /> Objective: On shutdown serialize the data contained in cookie_storage, hsts_list, and the new HTTP authorization cache, and write the serialized data in separate files inside the profile directory.<br /> <br /> When a Resource Thread exits we check if the opts structure located in opts.rs contains an entry for the command line option &quot;--profile dir&quot;. If the option is present when the Resource Thread exits we open or create a file for each data set we are saving. After each file is opened or created we serialize the data that corresponds to that file with the rust serialize library and save the serialized data to the file.<br /> <br /> The UML Diagram for this implementation can be found [http://wiki.expertiza.ncsu.edu/index.php/M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions#UML_for_step_2 here]<br /> <br /> === Step 3 ===<br /> <br /> Objective: On shutdown serialize the local_data in storage_thread.r<br /> <br /> This is similar to step 2 and some code re-use is used. However, the difference between this step and step 2 is that the local data contained in storage_thread.rs is the data that is being serialized and saved into the same directory.<br /> <br /> === Step 4 ===<br /> <br /> Objective: If the command line option for profile-dir is present then load the serialized data present in the directory that is given.<br /> <br /> When a resource thread is created we check if the opts structure located in opts.rs contains a entry for the command line option &quot;--profile dir&quot;. If the option is present then the data from each file contained in the directory is opened and deserialized using the serialize rust library. The data is then be placed in the appropriate fields. i.e (cookie_storage, hsts_lists, authorization_cache)<br /> <br /> The UML Diagram for this implementation can be found [http://wiki.expertiza.ncsu.edu/index.php/M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions#UML_for_step_4 here]<br /> <br /> '''The Pull Requests for these step can be found [http://wiki.expertiza.ncsu.edu/index.php/M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions#Subsequent_Steps_Pull_Requests here]'''<br /> <br /> =='''UML Diagrams'''==<br /> <br /> ==='''UML for step 1'''===<br /> <br /> [[File:517project.png ]]<br /> <br /> <br /> ==='''UML for step 2'''===<br /> <br /> [[File:STEP2.png ]]<br /> <br /> <br /> ==='''UML for step 4'''===<br /> <br /> [[File:STEP4.png ]]<br /> <br /> == '''Pull Requests''' ==<br /> All pull requests that fully implement the initial steps and the subsequent steps have been accepted by a servo maintainer and successfully merged to the servo master branch<br /> <br /> ==='''Initial Steps Pull Requests'''===<br /> <br /> These are the pull requests that complete the initial steps of the project:<br /> <br /> 1) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/servo/servo/pull/10087 Added a new command line flag --profile-dir ]&lt;/span&gt;<br /> <br /> 2) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/jdm/tinyfiledialogs/pull/1 Added Rust FFI bindings to lib.rs ]&lt;/span&gt;<br /> <br /> 3) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/servo/servo/pull/10111 Added authorization cache to resources &amp; set authorization header from it if url does not have credentials ]&lt;/span&gt;<br /> <br /> ==='''Subsequent Steps Pull Requests'''===<br /> <br /> These are the pull requests that complete the Final steps of the project:<br /> <br /> 1) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/servo/servo/pull/10328 401 authorization UI]&lt;/span&gt;<br /> <br /> 2) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/servo/servo/pull/10661 Writing the serialized data in separate files inside the profile directory]&lt;/span&gt;<br /> <br /> 3) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/servo/servo/pull/10800 Deserializing the data and populating the appropriate fields]&lt;/span&gt;<br /> <br /> <br /> =='''Testing'''==<br /> <br /> ==='''Testing the new command line flag --profile-dir'''===<br /> <br /> git clone https://github.com/servo/servo.git<br /> <br /> cd servo<br /> <br /> ./mach build --dev<br /> <br /> ./mach run tests/html/about-mozilla.html --profile-dir [directory name]<br /> <br /> //A new folder should be created if it does not exist with the directory name<br /> <br /> === '''Unit Test for set authorization header if url does not have credentials''' ===<br /> 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 <br /> <br /> It can be run with the other unit tests with the command <br /> <br /> ./mach test-unit -p net<br /> <br /> The unit test can be found in /servo/tests/unit/net/http_loader.rs<br /> <br /> === '''GUI test for the tinyfiledialogs lib'''===<br /> 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.<br /> <br /> To run the example and see all of the tinyfiledialog windows do the following.<br /> <br /> Git clone https://github.com/jdm/tinyfiledialogs.git<br /> <br /> cd tinyfiledialogs/examples/tinytest<br /> <br /> cargo run<br /> <br /> This will run tinytest which is a rust program that show cases the different GUI windows that the new rust tinyfiledialogs library has.<br /> <br /> =='''Conclusion'''==<br /> <br /> We have successfully completed all the steps mentioned in the [https://github.com/servo/servo/wiki/Persistent-sessions-student-project NCSU Student Projects Page]. All the Pull requests have been accepted and merged with the servo master branch. <br /> <br /> We have also created a [ Video] explaining our entire project<br /> <br /> =='''References'''==<br /> &lt;references/&gt;</div>

Mverma4 https://wiki.expertiza.ncsu.edu/index.php?title=M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions&diff=102307 2016-04-26T02:18:17Z

<p>Mverma4: </p> <hr /> <div>''' M1606: Implementing HTTP authorization UI and persistent sessions '''<br /> <br /> [https://en.wikipedia.org/wiki/Web_page Web pages] make use of [https://en.wikipedia.org/wiki/Session_(computer_science) 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.&lt;ref&gt; https://github.com/servo/servo/wiki/Persistent-sessions-student-project&lt;/ref&gt;<br /> <br /> With this project we have created the necessary infrastructure to support this.<br /> <br /> == '''Introduction''' ==<br /> <br /> <br /> === Servo ===<br /> <br /> <br /> [https://en.wikipedia.org/wiki/Servo_(layout_engine) 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.<br /> 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.&lt;ref&gt;https://en.wikipedia.org/wiki/Servo_(layout_engine)&lt;/ref&gt;<br /> <br /> === Rust ===<br /> <br /> [http://doc.rust-lang.org/book/README 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.<br /> 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.&lt;ref&gt;https://en.wikipedia.org/wiki/Rust_(programming_language)&lt;/ref&gt;<br /> <br /> == '''Previous Related Work''' ==<br /> <br /> '''A Wiki Page regarding this work can be found [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2016_OSS_M1606 here ]'''<br /> <br /> 1) Added a new command line flag &lt;code&gt; --profile-dir [path]&lt;/code&gt; that stores an optional directory path in the Opts struct in &lt;code&gt;opts.rs&lt;/code&gt;, creates the directory if it does not exist.<br /> <br /> <br /> 2) Created [http://doc.rust-lang.org/book/ffi.html Rust FFI bindings] for the &lt;code&gt;[https://github.com/jdm/tinyfiledialogs tinyfiledialogs] &lt;/code&gt;library to allow calling the C methods from Servo.<br /> <br /> <br /> 3) In &lt;code&gt;resource_thread.rs&lt;/code&gt;, defined an HTTP authorization cache storage (username, password, URL) and instantiated it like the cookie_storage member (inside an &lt;code&gt;Arc&lt;Rwlock&lt;&gt;&gt;&lt;/code&gt; value, to enable sharing it between threads).<br /> <br /> <br /> 4) In &lt;code&gt;modify_request_headers&lt;/code&gt; in &lt;code&gt;http_loader.rs&lt;/code&gt;, 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.<br /> <br /> ''' The Pull Requests for these steps can be found [http://wiki.expertiza.ncsu.edu/index.php/M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions#Initial_Steps_Pull_Requests here]'''<br /> <br /> == '''Scope''' ==<br /> The scope of the project comprises of the 4 steps listed below:<br /> <br /> 1) Ensure the appearance of an authorization UI in case a [https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html 401 HTTP response] is received. In load in the [https://github.com/servo/servo/blob/master/components/net/http_loader.rs http_loader.rs], immediately before attempting to process an HTTP redirection, the new [https://sourceforge.net/projects/tinyfiledialogs/ tinyfiledialogs] is made use of to make two prompts to pop up (for username and password), subsequently the request is restarted and the new authorization value present applied. If an authorization value was indeed present and the response is successful, the credentials are added to the authorization cache.<br /> <br /> 2) If the command-line option of the profile directory is present when the ResourceThread is instructed to exit, the data contained in the cookie_storage, hsts_list, and the new HTTP authorization cache is serialized. This serialized data is then written in separate files inside the profile directory.<br /> <br /> 3) Perform similar serialization upon shutdown for local_data in [https://doc.servo.org/src/net_traits/storage_thread.rs.html storage_thread.rs], which represents the LocalStorage API.<br /> <br /> 4) Check if the command-line option is present in the profile directory in the ResourceThreadconstructor and look for files that will contain serialized versions of the previous steps. If such files do exist, populate the appropriate fields with deserialized versions of the file’s contents.<br /> <br /> == '''Design Patterns''' ==<br /> 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]<br /> <br /> We do use a facade pattern by creating a safe RUST wrapper around the RUST FFI for the tinyfiledialogs library that we will use for the UI. We could have just called the FFI functions from servo, but instead we created a safe and simple interface to call the library functions.<br /> <br /> == '''Implementation / Design Decisions''' ==<br /> <br /> === Step 1 ===<br /> <br /> Objective: Make an authorization UI appear when a 401 HTTP response is received <br /> <br /> Using the tinyfiledialogs RUST FFI bindings that the team created in the initial steps we created a UI for the user to enter his username and password when a 401 request is received for a basic HTTP authentication. We then first check if the status code of the http response is &quot;unauthorized&quot;. If the code is unauthorized we then display the UI for the user to enter his username and password. After the username and password are entered the request is restarted with the authentication header added. If the request is successful we create a new authentication entry struct and place it into the Authentication hash map for future use.<br /> <br /> The UML Diagram for this implementation can be found [http://wiki.expertiza.ncsu.edu/index.php/M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions#UML_for_step_1 here]<br /> <br /> === Step 2 ===<br /> <br /> Objective: On shutdown serialize the data contained in cookie_storage, hsts_list, and the new HTTP authorization cache, and write the serialized data in separate files inside the profile directory.<br /> <br /> When a Resource Thread exits we check if the opts structure located in opts.rs contains an entry for the command line option &quot;--profile dir&quot;. If the option is present when the Resource Thread exits we open or create a file for each data set we are saving. After each file is opened or created we serialize the data that corresponds to that file with the rust serialize library and save the serialized data to the file.<br /> <br /> The UML Diagram for this implementation can be found [http://wiki.expertiza.ncsu.edu/index.php/M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions#UML_for_step_2 here]<br /> <br /> === Step 3 ===<br /> <br /> Objective: On shutdown serialize the local_data in storage_thread.r<br /> <br /> This is similar to step 2 and some code re-use is used. However, the difference between this step and step 2 is that the local data contained in storage_thread.rs is the data that is being serialized and saved into the same directory.<br /> <br /> === Step 4 ===<br /> <br /> Objective: If the command line option for profile-dir is present then load the serialized data present in the directory that is given.<br /> <br /> When a resource thread is created we check if the opts structure located in opts.rs contains a entry for the command line option &quot;--profile dir&quot;. If the option is present then the data from each file contained in the directory is opened and deserialized using the serialize rust library. The data is then be placed in the appropriate fields. i.e (cookie_storage, hsts_lists, authorization_cache)<br /> <br /> The UML Diagram for this implementation can be found [http://wiki.expertiza.ncsu.edu/index.php/M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions#UML_for_step_4 here]<br /> <br /> '''The Pull Requests for these step can be found [http://wiki.expertiza.ncsu.edu/index.php/M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions#Subsequent_Steps_Pull_Requests here]'''<br /> <br /> =='''UML Diagrams'''==<br /> <br /> ==='''UML for step 1'''===<br /> <br /> [[File:517project.png ]]<br /> <br /> <br /> ==='''UML for step 2'''===<br /> <br /> [[File:STEP2.png ]]<br /> <br /> <br /> ==='''UML for step 4'''===<br /> <br /> [[File:STEP4.png ]]<br /> <br /> == '''Pull Requests''' ==<br /> All pull requests that fully implement the initial steps and the subsequent steps have been accepted by a servo maintainer and successfully merged to the servo master branch<br /> <br /> ==='''Initial Steps Pull Requests'''===<br /> <br /> These are the pull requests that complete the initial steps of the project:<br /> <br /> 1) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/servo/servo/pull/10087 Added a new command line flag --profile-dir ]&lt;/span&gt;<br /> <br /> 2) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/jdm/tinyfiledialogs/pull/1 Added Rust FFI bindings to lib.rs ]&lt;/span&gt;<br /> <br /> 3) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/servo/servo/pull/10111 Added authorization cache to resources &amp; set authorization header from it if url does not have credentials ]&lt;/span&gt;<br /> <br /> ==='''Subsequent Steps Pull Requests'''===<br /> <br /> These are the pull requests that complete the Final steps of the project:<br /> <br /> 1) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/servo/servo/pull/10328 401 authorization UI]&lt;/span&gt;<br /> <br /> 2) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/servo/servo/pull/10661 Writing the serialized data in separate files inside the profile directory]&lt;/span&gt;<br /> <br /> 3) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/servo/servo/pull/10800 Deserializing the data and populating the appropriate fields]&lt;/span&gt;<br /> <br /> <br /> =='''Testing'''==<br /> <br /> ==='''Testing the new command line flag --profile-dir'''===<br /> <br /> git clone https://github.com/servo/servo.git<br /> <br /> cd servo<br /> <br /> ./mach build --dev<br /> <br /> ./mach run tests/html/about-mozilla.html --profile-dir [directory name]<br /> <br /> //A new folder should be created if it does not exist with the directory name<br /> <br /> === '''Unit Test for set authorization header if url does not have credentials''' ===<br /> 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 <br /> <br /> It can be run with the other unit tests with the command <br /> <br /> ./mach test-unit -p net<br /> <br /> The unit test can be found in /servo/tests/unit/net/http_loader.rs<br /> <br /> === '''GUI test for the tinyfiledialogs lib'''===<br /> 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.<br /> <br /> To run the example and see all of the tinyfiledialog windows do the following.<br /> <br /> Git clone https://github.com/jdm/tinyfiledialogs.git<br /> <br /> cd tinyfiledialogs/examples/tinytest<br /> <br /> cargo run<br /> <br /> This will run tinytest which is a rust program that show cases the different GUI windows that the new rust tinyfiledialogs library has.<br /> <br /> =='''Conclusion'''==<br /> <br /> We have successfully completed all the steps mentioned in the [https://github.com/servo/servo/wiki/Persistent-sessions-student-project Ncsu Student Projects Page]. All the Pull requests have been accepted and merged with the servo master branch. <br /> <br /> We have also created a [ Video] explaining our entire project<br /> <br /> =='''References'''==<br /> &lt;references/&gt;</div>

Mverma4 https://wiki.expertiza.ncsu.edu/index.php?title=M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions&diff=102301 2016-04-26T01:57:28Z

<p>Mverma4: </p> <hr /> <div>''' M1606: Implementing HTTP authorization UI and persistent sessions '''<br /> <br /> [https://en.wikipedia.org/wiki/Web_page Web pages] make use of [https://en.wikipedia.org/wiki/Session_(computer_science) 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.&lt;ref&gt; https://github.com/servo/servo/wiki/Persistent-sessions-student-project&lt;/ref&gt;<br /> <br /> With this project we aim to create the necessary infrastructure to support this.<br /> <br /> == '''Introduction''' ==<br /> <br /> <br /> === Servo ===<br /> <br /> <br /> [https://en.wikipedia.org/wiki/Servo_(layout_engine) 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.<br /> 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.&lt;ref&gt;https://en.wikipedia.org/wiki/Servo_(layout_engine)&lt;/ref&gt;<br /> <br /> === Rust ===<br /> <br /> [http://doc.rust-lang.org/book/README 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.<br /> 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.&lt;ref&gt;https://en.wikipedia.org/wiki/Rust_(programming_language)&lt;/ref&gt;<br /> <br /> == '''Previous Related Work''' ==<br /> <br /> '''A Wiki Page regarding this work can be found [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2016_OSS_M1606 here ]'''<br /> <br /> 1) Added a new command line flag &lt;code&gt; --profile-dir [path]&lt;/code&gt; that stores an optional directory path in the Opts struct in &lt;code&gt;opts.rs&lt;/code&gt;, creates the directory if it does not exist.<br /> <br /> <br /> 2) Created [http://doc.rust-lang.org/book/ffi.html Rust FFI bindings] for the &lt;code&gt;[https://github.com/jdm/tinyfiledialogs tinyfiledialogs] &lt;/code&gt;library to allow calling the C methods from Servo.<br /> <br /> <br /> 3) In &lt;code&gt;resource_thread.rs&lt;/code&gt;, defined an HTTP authorization cache storage (username, password, URL) and instantiated it like the cookie_storage member (inside an &lt;code&gt;Arc&lt;Rwlock&lt;&gt;&gt;&lt;/code&gt; value, to enable sharing it between threads).<br /> <br /> <br /> 4) In &lt;code&gt;modify_request_headers&lt;/code&gt; in &lt;code&gt;http_loader.rs&lt;/code&gt;, 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.<br /> <br /> ''' The Pull Requests for these steps can be found [http://wiki.expertiza.ncsu.edu/index.php/M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions#Initial_Steps_Pull_Requests here]'''<br /> <br /> == '''Scope''' ==<br /> The scope of the project comprises of the 4 steps listed below:<br /> <br /> 1) Ensure the appearance of an authorization UI in case a [https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html 401 HTTP response] is received. In load in the [https://github.com/servo/servo/blob/master/components/net/http_loader.rs http_loader.rs], immediately before attempting to process an HTTP redirection, the new [https://sourceforge.net/projects/tinyfiledialogs/ tinyfiledialogs] is made use of to make two prompts to pop up (for username and password), subsequently the request is restarted and the new authorization value present applied. If an authorization value was indeed present and the response is successful, the credentials are added to the authorization cache.<br /> <br /> 2) If the command-line option of the profile directory is present when the ResourceThread is instructed to exit, the data contained in the cookie_storage, hsts_list, and the new HTTP authorization cache is serialized. This serialized data is then written in separate files inside the profile directory.<br /> <br /> 3) Perform similar serialization upon shutdown for local_data in [https://doc.servo.org/src/net_traits/storage_thread.rs.html storage_thread.rs], which represents the LocalStorage API.<br /> <br /> 4) Check if the command-line option is present in the profile directory in the ResourceThreadconstructor and look for files that will contain serialized versions of the previous steps. If such files do exist, populate the appropriate fields with deserialized versions of the file’s contents.<br /> <br /> == '''Design Patterns''' ==<br /> 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]<br /> <br /> We do use a facade pattern by creating a safe RUST wrapper around the RUST FFI for the tinyfiledialogs library that we will use for the UI. We could have just called the FFI functions from servo, but instead we created a safe and simple interface to call the library functions.<br /> <br /> == '''Implementation / Design Decisions''' ==<br /> <br /> Here are some of the design decisions that we have made for implementing the steps mentioned in [http://wiki.expertiza.ncsu.edu/index.php/M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions#Scope Scope] :<br /> <br /> === Step 1 ===<br /> <br /> Objective: Make an authorization UI appear when a 401 HTTP response is received <br /> <br /> Using the tinyfiledialogs RUST FFI bindings that the team created in the initial steps we created a UI for the user to enter his username and password when a 401 request is received for a basic HTTP authentication. We then first check if the status code of the http response is &quot;unauthorized&quot;. If the code is unauthorized we then display the UI for the user to enter his username and password. After the username and password are entered the request is restarted with the authentication header added. If the request is successful we create a new authentication entry struct and place it into the Authentication hash map for future use.<br /> <br /> The UML Diagram for this implementation can be found [http://wiki.expertiza.ncsu.edu/index.php/M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions#UML_for_step_1 here]<br /> <br /> === Step 2 ===<br /> <br /> Objective: On shutdown serialize the data contained in cookie_storage, hsts_list, and the new HTTP authorization cache, and write the serialized data in separate files inside the profile directory.<br /> <br /> When a Resource Thread exits we check if the opts structure located in opts.rs contains an entry for the command line option &quot;--profile dir&quot;. If the option is present when the Resource Thread exits we open or create a file for each data set we are saving. After each file is opened or created we serialize the data that corresponds to that file with the rust serialize library and save the serialized data to the file.<br /> <br /> The UML Diagram for this implementation can be found [http://wiki.expertiza.ncsu.edu/index.php/M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions#UML_for_step_2 here]<br /> <br /> === Step 3 ===<br /> <br /> Objective: On shutdown serialize the local_data in storage_thread.r<br /> <br /> This is similar to step 2 and some code re-use is used. However, the difference between this step and step 2 is that the local data contained in storage_thread.rs is the data that is being serialized and saved into the same directory.<br /> <br /> === Step 4 ===<br /> <br /> Objective: If the command line option for profile-dir is present then load the serialized data present in the directory that is given.<br /> <br /> When a resource thread is created we check if the opts structure located in opts.rs contains a entry for the command line option &quot;--profile dir&quot;. If the option is present then the data from each file contained in the directory is opened and deserialized using the serialize rust library. The data is then be placed in the appropriate fields. i.e (cookie_storage, hsts_lists, authorization_cache)<br /> <br /> The UML Diagram for this implementation can be found [http://wiki.expertiza.ncsu.edu/index.php/M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions#UML_for_step_4 here]<br /> <br /> '''The Pull Requests for these step can be found [http://wiki.expertiza.ncsu.edu/index.php/M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions#Subsequent_Steps_Pull_Requests here]'''<br /> <br /> =='''UML Diagrams'''==<br /> <br /> ==='''UML for step 1'''===<br /> <br /> [[File:517project.png ]]<br /> <br /> <br /> ==='''UML for step 2'''===<br /> <br /> [[File:STEP2.png ]]<br /> <br /> <br /> ==='''UML for step 4'''===<br /> <br /> [[File:STEP4.png ]]<br /> <br /> == '''Pull Requests''' ==<br /> All pull requests that fully implement the initial steps have been accepted by a servo maintainer and successfully merged to the servo master branch<br /> <br /> ==='''Initial Steps Pull Requests'''===<br /> <br /> These are the pull requests that complete the initial steps of the project:<br /> <br /> 1) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/servo/servo/pull/10087 Added a new command line flag --profile-dir ]&lt;/span&gt;<br /> <br /> 2) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/jdm/tinyfiledialogs/pull/1 Added Rust FFI bindings to lib.rs ]&lt;/span&gt;<br /> <br /> 3) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/servo/servo/pull/10111 Added authorization cache to resources &amp; set authorization header from it if url does not have credentials ]&lt;/span&gt;<br /> <br /> ==='''Subsequent Steps Pull Requests'''===<br /> <br /> These are the pull requests that complete the Final steps of the project:<br /> <br /> 1) &lt;span class=&quot;plainlinks&quot;&gt;[ Pull1 here ]&lt;/span&gt;<br /> <br /> 2) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/jdm/tinyfiledialogs/pull/1 Pull2 here]&lt;/span&gt;<br /> <br /> 3) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/servo/servo/pull/10111 Pull3 here ]&lt;/span&gt;<br /> <br /> <br /> =='''Testing'''==<br /> <br /> ==='''Testing the new command line flag --profile-dir'''===<br /> <br /> git clone https://github.com/servo/servo.git<br /> <br /> cd servo<br /> <br /> ./mach build --dev<br /> <br /> ./mach run tests/html/about-mozilla.html --profile-dir [directory name]<br /> <br /> //A new folder should be created if it does not exist with the directory name<br /> <br /> === '''Unit Test for set authorization header if url does not have credentials''' ===<br /> 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 <br /> <br /> It can be run with the other unit tests with the command <br /> <br /> ./mach test-unit -p net<br /> <br /> The unit test can be found in /servo/tests/unit/net/http_loader.rs<br /> <br /> === '''GUI test for the tinyfiledialogs lib'''===<br /> 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.<br /> <br /> To run the example and see all of the tinyfiledialog windows do the following.<br /> <br /> Git clone https://github.com/jdm/tinyfiledialogs.git<br /> <br /> cd tinyfiledialogs/examples/tinytest<br /> <br /> cargo run<br /> <br /> This will run tinytest which is a rust program that show cases the different GUI windows that the new rust tinyfiledialogs library has.<br /> <br /> =='''Conclusion'''==<br /> <br /> As mentioned earlier we have completed the initial steps and they have been fully merged with the servo master branch. We are in the process of completing the subsequent steps. One pull request has been made and we are currently adding some changes to it in order to implement the first subsequent step &quot;make an authorization UI appear when a 401 HTTP response is received &quot;. The pull request can be found [https://github.com/servo/servo/pull/10328 here]. We have also started work on the second step, however, have not made the second pull request yet.<br /> <br /> =='''References'''==<br /> &lt;references/&gt;</div>

Mverma4 https://wiki.expertiza.ncsu.edu/index.php?title=M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions&diff=102300 2016-04-26T01:54:52Z

<p>Mverma4: </p> <hr /> <div>''' M1606: Implementing HTTP authorization UI and persistent sessions '''<br /> <br /> [https://en.wikipedia.org/wiki/Web_page Web pages] make use of [https://en.wikipedia.org/wiki/Session_(computer_science) 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.&lt;ref&gt; https://github.com/servo/servo/wiki/Persistent-sessions-student-project&lt;/ref&gt;<br /> <br /> With this project we aim to create the necessary infrastructure to support this.<br /> <br /> == '''Introduction''' ==<br /> <br /> <br /> === Servo ===<br /> <br /> <br /> [https://en.wikipedia.org/wiki/Servo_(layout_engine) 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.<br /> 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.&lt;ref&gt;https://en.wikipedia.org/wiki/Servo_(layout_engine)&lt;/ref&gt;<br /> <br /> === Rust ===<br /> <br /> [http://doc.rust-lang.org/book/README 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.<br /> 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.&lt;ref&gt;https://en.wikipedia.org/wiki/Rust_(programming_language)&lt;/ref&gt;<br /> <br /> == '''Previous Related Work''' ==<br /> <br /> '''A Wiki Page regarding this work can be found [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2016_OSS_M1606 here ]'''<br /> <br /> 1) Added a new command line flag &lt;code&gt; --profile-dir [path]&lt;/code&gt; that stores an optional directory path in the Opts struct in &lt;code&gt;opts.rs&lt;/code&gt;, creates the directory if it does not exist.<br /> <br /> <br /> 2) Created [http://doc.rust-lang.org/book/ffi.html Rust FFI bindings] for the &lt;code&gt;[https://github.com/jdm/tinyfiledialogs tinyfiledialogs] &lt;/code&gt;library to allow calling the C methods from Servo.<br /> <br /> <br /> 3) In &lt;code&gt;resource_thread.rs&lt;/code&gt;, defined an HTTP authorization cache storage (username, password, URL) and instantiated it like the cookie_storage member (inside an &lt;code&gt;Arc&lt;Rwlock&lt;&gt;&gt;&lt;/code&gt; value, to enable sharing it between threads).<br /> <br /> <br /> 4) In &lt;code&gt;modify_request_headers&lt;/code&gt; in &lt;code&gt;http_loader.rs&lt;/code&gt;, 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.<br /> <br /> ''' The Pull Requests for these steps can be found [ http://wiki.expertiza.ncsu.edu/index.php/M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions#Initial_Steps_Pull_Requests here ]'''<br /> <br /> == '''Scope''' ==<br /> The scope of the project comprises of the 4 steps listed below:<br /> <br /> 1) Ensure the appearance of an authorization UI in case a [https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html 401 HTTP response] is received. In load in the [https://github.com/servo/servo/blob/master/components/net/http_loader.rs http_loader.rs], immediately before attempting to process an HTTP redirection, the new [https://sourceforge.net/projects/tinyfiledialogs/ tinyfiledialogs] is made use of to make two prompts to pop up (for username and password), subsequently the request is restarted and the new authorization value present applied. If an authorization value was indeed present and the response is successful, the credentials are added to the authorization cache.<br /> <br /> 2) If the command-line option of the profile directory is present when the ResourceThread is instructed to exit, the data contained in the cookie_storage, hsts_list, and the new HTTP authorization cache is serialized. This serialized data is then written in separate files inside the profile directory.<br /> <br /> 3) Perform similar serialization upon shutdown for local_data in [https://doc.servo.org/src/net_traits/storage_thread.rs.html storage_thread.rs], which represents the LocalStorage API.<br /> <br /> 4) Check if the command-line option is present in the profile directory in the ResourceThreadconstructor and look for files that will contain serialized versions of the previous steps. If such files do exist, populate the appropriate fields with deserialized versions of the file’s contents.<br /> <br /> == '''Design Patterns''' ==<br /> 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]<br /> <br /> We do use a facade pattern by creating a safe RUST wrapper around the RUST FFI for the tinyfiledialogs library that we will use for the UI. We could have just called the FFI functions from servo, but instead we created a safe and simple interface to call the library functions.<br /> <br /> == '''Implementation / Design Decisions''' ==<br /> <br /> Here are some of the design decisions that we have made for implementing the steps mentioned in [http://wiki.expertiza.ncsu.edu/index.php/M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions#Scope Scope] :<br /> <br /> === Step 1 ===<br /> <br /> Objective: Make an authorization UI appear when a 401 HTTP response is received <br /> <br /> Using the tinyfiledialogs RUST FFI bindings that the team created in the initial steps we created a UI for the user to enter his username and password when a 401 request is received for a basic HTTP authentication. We then first check if the status code of the http response is &quot;unauthorized&quot;. If the code is unauthorized we then display the UI for the user to enter his username and password. After the username and password are entered the request is restarted with the authentication header added. If the request is successful we create a new authentication entry struct and place it into the Authentication hash map for future use.<br /> <br /> The UML Diagram for this implementation can be found [http://wiki.expertiza.ncsu.edu/index.php/M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions#UML_for_step_1 here]<br /> <br /> === Step 2 ===<br /> <br /> Objective: On shutdown serialize the data contained in cookie_storage, hsts_list, and the new HTTP authorization cache, and write the serialized data in separate files inside the profile directory.<br /> <br /> When a Resource Thread exits we check if the opts structure located in opts.rs contains an entry for the command line option &quot;--profile dir&quot;. If the option is present when the Resource Thread exits we open or create a file for each data set we are saving. After each file is opened or created we serialize the data that corresponds to that file with the rust serialize library and save the serialized data to the file.<br /> <br /> The UML Diagram for this implementation can be found [http://wiki.expertiza.ncsu.edu/index.php/M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions#UML_for_step_2 here]<br /> <br /> === Step 3 ===<br /> <br /> Objective: On shutdown serialize the local_data in storage_thread.r<br /> <br /> This is similar to step 2 and some code re-use is used. However, the difference between this step and step 2 is that the local data contained in storage_thread.rs is the data that is being serialized and saved into the same directory.<br /> <br /> === Step 4 ===<br /> <br /> Objective: If the command line option for profile-dir is present then load the serialized data present in the directory that is given.<br /> <br /> When a resource thread is created we check if the opts structure located in opts.rs contains a entry for the command line option &quot;--profile dir&quot;. If the option is present then the data from each file contained in the directory is opened and deserialized using the serialize rust library. The data is then be placed in the appropriate fields. i.e (cookie_storage, hsts_lists, authorization_cache)<br /> <br /> The UML Diagram for this implementation can be found [http://wiki.expertiza.ncsu.edu/index.php/M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions#UML_for_step_4 here]<br /> <br /> '''The Pull Requests for these step can be found [ http://wiki.expertiza.ncsu.edu/index.php/M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions#Subsequent_Steps_Pull_Requests here ]'''<br /> <br /> =='''UML Diagrams'''==<br /> <br /> ==='''UML for step 1'''===<br /> <br /> [[File:517project.png ]]<br /> <br /> <br /> ==='''UML for step 2'''===<br /> <br /> [[File:STEP2.png ]]<br /> <br /> <br /> ==='''UML for step 4'''===<br /> <br /> [[File:STEP4.png ]]<br /> <br /> == '''Pull Requests''' ==<br /> All pull requests that fully implement the initial steps have been accepted by a servo maintainer and successfully merged to the servo master branch<br /> <br /> ==='''Initial Steps Pull Requests'''===<br /> <br /> These are the pull requests that complete the initial steps of the project:<br /> <br /> 1) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/servo/servo/pull/10087 Added a new command line flag --profile-dir ]&lt;/span&gt;<br /> <br /> 2) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/jdm/tinyfiledialogs/pull/1 Added Rust FFI bindings to lib.rs ]&lt;/span&gt;<br /> <br /> 3) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/servo/servo/pull/10111 Added authorization cache to resources &amp; set authorization header from it if url does not have credentials ]&lt;/span&gt;<br /> <br /> ==='''Subsequent Steps Pull Requests'''===<br /> <br /> These are the pull requests that complete the Final steps of the project:<br /> <br /> 1) &lt;span class=&quot;plainlinks&quot;&gt;[ Pull1 here ]&lt;/span&gt;<br /> <br /> 2) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/jdm/tinyfiledialogs/pull/1 Pull2 here]&lt;/span&gt;<br /> <br /> 3) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/servo/servo/pull/10111 Pull3 here ]&lt;/span&gt;<br /> <br /> <br /> =='''Testing'''==<br /> <br /> ==='''Testing the new command line flag --profile-dir'''===<br /> <br /> git clone https://github.com/servo/servo.git<br /> <br /> cd servo<br /> <br /> ./mach build --dev<br /> <br /> ./mach run tests/html/about-mozilla.html --profile-dir [directory name]<br /> <br /> //A new folder should be created if it does not exist with the directory name<br /> <br /> === '''Unit Test for set authorization header if url does not have credentials''' ===<br /> 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 <br /> <br /> It can be run with the other unit tests with the command <br /> <br /> ./mach test-unit -p net<br /> <br /> The unit test can be found in /servo/tests/unit/net/http_loader.rs<br /> <br /> === '''GUI test for the tinyfiledialogs lib'''===<br /> 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.<br /> <br /> To run the example and see all of the tinyfiledialog windows do the following.<br /> <br /> Git clone https://github.com/jdm/tinyfiledialogs.git<br /> <br /> cd tinyfiledialogs/examples/tinytest<br /> <br /> cargo run<br /> <br /> This will run tinytest which is a rust program that show cases the different GUI windows that the new rust tinyfiledialogs library has.<br /> <br /> =='''Conclusion'''==<br /> <br /> As mentioned earlier we have completed the initial steps and they have been fully merged with the servo master branch. We are in the process of completing the subsequent steps. One pull request has been made and we are currently adding some changes to it in order to implement the first subsequent step &quot;make an authorization UI appear when a 401 HTTP response is received &quot;. The pull request can be found [https://github.com/servo/servo/pull/10328 here]. We have also started work on the second step, however, have not made the second pull request yet.<br /> <br /> =='''References'''==<br /> &lt;references/&gt;</div>

Mverma4 https://wiki.expertiza.ncsu.edu/index.php?title=M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions&diff=102299 2016-04-26T01:27:16Z

<p>Mverma4: </p> <hr /> <div>''' M1606: Implementing HTTP authorization UI and persistent sessions '''<br /> <br /> [https://en.wikipedia.org/wiki/Web_page Web pages] make use of [https://en.wikipedia.org/wiki/Session_(computer_science) 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.&lt;ref&gt; https://github.com/servo/servo/wiki/Persistent-sessions-student-project&lt;/ref&gt;<br /> <br /> With this project we aim to create the necessary infrastructure to support this.<br /> <br /> == '''Introduction''' ==<br /> <br /> <br /> === Servo ===<br /> <br /> <br /> [https://en.wikipedia.org/wiki/Servo_(layout_engine) 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.<br /> 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.&lt;ref&gt;https://en.wikipedia.org/wiki/Servo_(layout_engine)&lt;/ref&gt;<br /> <br /> === Rust ===<br /> <br /> [http://doc.rust-lang.org/book/README 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.<br /> 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.&lt;ref&gt;https://en.wikipedia.org/wiki/Rust_(programming_language)&lt;/ref&gt;<br /> <br /> == '''Previous Related Work''' ==<br /> <br /> '''A Wiki Page regarding this work can be found [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2016_OSS_M1606 here ]'''<br /> <br /> 1) Added a new command line flag &lt;code&gt; --profile-dir [path]&lt;/code&gt; that stores an optional directory path in the Opts struct in &lt;code&gt;opts.rs&lt;/code&gt;, creates the directory if it does not exist.<br /> <br /> <br /> 2) Created [http://doc.rust-lang.org/book/ffi.html Rust FFI bindings] for the &lt;code&gt;[https://github.com/jdm/tinyfiledialogs tinyfiledialogs] &lt;/code&gt;library to allow calling the C methods from Servo.<br /> <br /> <br /> 3) In &lt;code&gt;resource_thread.rs&lt;/code&gt;, defined an HTTP authorization cache storage (username, password, URL) and instantiated it like the cookie_storage member (inside an &lt;code&gt;Arc&lt;Rwlock&lt;&gt;&gt;&lt;/code&gt; value, to enable sharing it between threads).<br /> <br /> <br /> 4) In &lt;code&gt;modify_request_headers&lt;/code&gt; in &lt;code&gt;http_loader.rs&lt;/code&gt;, 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.<br /> <br /> == '''Scope''' ==<br /> The scope of the project comprises of the 4 steps listed below:<br /> <br /> 1) Ensure the appearance of an authorization UI in case a [https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html 401 HTTP response] is received. In load in the [https://github.com/servo/servo/blob/master/components/net/http_loader.rs http_loader.rs], immediately before attempting to process an HTTP redirection, the new [https://sourceforge.net/projects/tinyfiledialogs/ tinyfiledialogs] is made use of to make two prompts to pop up (for username and password), subsequently the request is restarted and the new authorization value present applied. If an authorization value was indeed present and the response is successful, the credentials are added to the authorization cache.<br /> <br /> 2) If the command-line option of the profile directory is present when the ResourceThread is instructed to exit, the data contained in the cookie_storage, hsts_list, and the new HTTP authorization cache is serialized. This serialized data is then written in separate files inside the profile directory.<br /> <br /> 3) Perform similar serialization upon shutdown for local_data in [https://doc.servo.org/src/net_traits/storage_thread.rs.html storage_thread.rs], which represents the LocalStorage API.<br /> <br /> 4) Check if the command-line option is present in the profile directory in the ResourceThreadconstructor and look for files that will contain serialized versions of the previous steps. If such files do exist, populate the appropriate fields with deserialized versions of the file’s contents.<br /> <br /> == '''Design Patterns''' ==<br /> 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]<br /> <br /> We do use a facade pattern by creating a safe RUST wrapper around the RUST FFI for the tinyfiledialogs library that we will use for the UI. We could have just called the FFI functions from servo, but instead we created a safe and simple interface to call the library functions.<br /> <br /> == '''Implementation / Design Decisions''' ==<br /> <br /> Here are some of the design decisions that we have made for implementing the steps mentioned in [http://wiki.expertiza.ncsu.edu/index.php/M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions#Scope Scope] :<br /> <br /> === Step 1 ===<br /> <br /> Objective: Make an authorization UI appear when a 401 HTTP response is received <br /> <br /> Using the tinyfiledialogs RUST FFI bindings that the team created in the initial steps we will create a UI for the user to enter his username and password when a 401 request is received for a basic HTTP authentication. We will first check if the status code of the http response is &quot;unauthorized&quot;. If the code is unauthorized we will display the UI for the user to enter his username and password. After the username and password are entered the request is restarted with the authentication header added. If the request is now successful we create a new authentication entry struct and place it into the Authentication hash map for future use.<br /> <br /> The UML Diagram for this implementation can be found [http://wiki.expertiza.ncsu.edu/index.php/M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions#UML_for_step_1 here]<br /> <br /> === Step 2 ===<br /> <br /> Objective: On shutdown serialize the data contained in cookie_storage, hsts_list, and the new HTTP authorization cache, and write the serialized data in separate files inside the profile directory.<br /> <br /> When a Resource Thread exits we will check if the opts structure located in opts.rs contains an entry for the command line option &quot;--profile dir&quot;. If the option is present when the Resource Thread exits we will open or create a file for each data set we are saving. After each file is opened or created we will serialize the data that corresponds to that file with the rust serialize library and save the serialized data to the file.<br /> <br /> The UML Diagram for this implementation can be found [http://wiki.expertiza.ncsu.edu/index.php/M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions#UML_for_step_2 here]<br /> <br /> === Step 3 ===<br /> <br /> Objective: On shutdown serialize the local_data in storage_thread.r<br /> <br /> This is similar to step 2 and some code re-use will be used. However, the difference between this step and step 2 is that the local data contained in storage_thread.rs will be the data that is being serialized and saved into the same directory.<br /> <br /> === Step 4 ===<br /> <br /> Objective: If the command line option for profile-dir is present then load the serialized data present in the directory that is given.<br /> <br /> When a resource thread is created we will check if the opts structure located in opts.rs contains a entry for the command line option &quot;--profile dir&quot;. If the option is present then the data from each file contained in the directory will be opened and deserialized using the serialize rust library. The data will then be placed in the appropriate fields. i.e (cookie_storage, hsts_lists, authorization_cache)<br /> <br /> The UML Diagram for this implementation can be found [http://wiki.expertiza.ncsu.edu/index.php/M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions#UML_for_step_4 here]<br /> <br /> =='''UML Diagrams'''==<br /> <br /> ==='''UML for step 1'''===<br /> <br /> [[File:517project.png ]]<br /> <br /> <br /> ==='''UML for step 2'''===<br /> <br /> [[File:STEP2.png ]]<br /> <br /> <br /> ==='''UML for step 4'''===<br /> <br /> [[File:STEP4.png ]]<br /> <br /> == '''Pull Requests''' ==<br /> All pull requests that fully implement the initial steps have been accepted by a servo maintainer and successfully merged to the servo master branch<br /> <br /> ==='''Initial Steps Pull Requests'''===<br /> <br /> These are the pull requests that complete the initial steps of the project:<br /> <br /> 1) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/servo/servo/pull/10087 Added a new command line flag --profile-dir ]&lt;/span&gt;<br /> <br /> 2) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/jdm/tinyfiledialogs/pull/1 Added Rust FFI bindings to lib.rs ]&lt;/span&gt;<br /> <br /> 3) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/servo/servo/pull/10111 Added authorization cache to resources &amp; set authorization header from it if url does not have credentials ]&lt;/span&gt;<br /> <br /> ==='''Subsequent Steps Pull Requests'''===<br /> <br /> These are the pull requests that complete the initial steps of the project:<br /> <br /> 1) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/servo/servo/pull/10087 Pull1 here ]&lt;/span&gt;<br /> <br /> 2) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/jdm/tinyfiledialogs/pull/1 Pull2 here]&lt;/span&gt;<br /> <br /> 3) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/servo/servo/pull/10111 Pull3 here ]&lt;/span&gt;<br /> <br /> <br /> =='''Testing'''==<br /> <br /> ==='''Testing the new command line flag --profile-dir'''===<br /> <br /> git clone https://github.com/servo/servo.git<br /> <br /> cd servo<br /> <br /> ./mach build --dev<br /> <br /> ./mach run tests/html/about-mozilla.html --profile-dir [directory name]<br /> <br /> //A new folder should be created if it does not exist with the directory name<br /> <br /> === '''Unit Test for set authorization header if url does not have credentials''' ===<br /> 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 <br /> <br /> It can be run with the other unit tests with the command <br /> <br /> ./mach test-unit -p net<br /> <br /> The unit test can be found in /servo/tests/unit/net/http_loader.rs<br /> <br /> === '''GUI test for the tinyfiledialogs lib'''===<br /> 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.<br /> <br /> To run the example and see all of the tinyfiledialog windows do the following.<br /> <br /> Git clone https://github.com/jdm/tinyfiledialogs.git<br /> <br /> cd tinyfiledialogs/examples/tinytest<br /> <br /> cargo run<br /> <br /> This will run tinytest which is a rust program that show cases the different GUI windows that the new rust tinyfiledialogs library has.<br /> <br /> =='''Conclusion'''==<br /> <br /> As mentioned earlier we have completed the initial steps and they have been fully merged with the servo master branch. We are in the process of completing the subsequent steps. One pull request has been made and we are currently adding some changes to it in order to implement the first subsequent step &quot;make an authorization UI appear when a 401 HTTP response is received &quot;. The pull request can be found [https://github.com/servo/servo/pull/10328 here]. We have also started work on the second step, however, have not made the second pull request yet.<br /> <br /> =='''References'''==<br /> &lt;references/&gt;</div>

Mverma4 https://wiki.expertiza.ncsu.edu/index.php?title=M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions&diff=102180 2016-04-12T00:17:56Z

<p>Mverma4: /* Implementation / Design Decisions */</p> <hr /> <div>''' M1606: Implementing HTTP authorization UI and persistent sessions '''<br /> <br /> [https://en.wikipedia.org/wiki/Web_page Web pages] make use of [https://en.wikipedia.org/wiki/Session_(computer_science) 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.&lt;ref&gt; https://github.com/servo/servo/wiki/Persistent-sessions-student-project&lt;/ref&gt;<br /> <br /> With this project we aim to create the necessary infrastructure to support this.<br /> <br /> == '''Introduction''' ==<br /> <br /> <br /> === Servo ===<br /> <br /> <br /> [https://en.wikipedia.org/wiki/Servo_(layout_engine) 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.<br /> 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.&lt;ref&gt;https://en.wikipedia.org/wiki/Servo_(layout_engine)&lt;/ref&gt;<br /> <br /> === Rust ===<br /> <br /> [http://doc.rust-lang.org/book/README 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.<br /> 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.&lt;ref&gt;https://en.wikipedia.org/wiki/Rust_(programming_language)&lt;/ref&gt;<br /> <br /> == '''Previous Related Work''' ==<br /> <br /> '''A Wiki Page regarding this work can be found [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2016_OSS_M1606 here ]'''<br /> <br /> 1) Added a new command line flag &lt;code&gt; --profile-dir [path]&lt;/code&gt; that stores an optional directory path in the Opts struct in &lt;code&gt;opts.rs&lt;/code&gt;, creates the directory if it does not exist.<br /> <br /> [[File:Step2Wiki2spring16.jpg]]<br /> <br /> 2) Created [http://doc.rust-lang.org/book/ffi.html Rust FFI bindings] for the &lt;code&gt;[https://github.com/jdm/tinyfiledialogs tinyfiledialogs] &lt;/code&gt;library to allow calling the C methods from Servo.<br /> <br /> [[File:Step3-1Wiki2spring16.jpg]]<br /> <br /> [[File:Step3-2Wiki2spring16.jpg]]<br /> <br /> 3) In &lt;code&gt;resource_thread.rs&lt;/code&gt;, defined an HTTP authorization cache storage (username, password, URL) and instantiated it like the cookie_storage member (inside an &lt;code&gt;Arc&lt;Rwlock&lt;&gt;&gt;&lt;/code&gt; value, to enable sharing it between threads).<br /> <br /> [[File:Step4Wiki2spring16.jpg]]<br /> <br /> 4) In &lt;code&gt;modify_request_headers&lt;/code&gt; in &lt;code&gt;http_loader.rs&lt;/code&gt;, 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.<br /> <br /> [[File:Step5Wiki2spring16.jpg]]<br /> <br /> == '''Scope''' ==<br /> The scope of the project comprises of the 4 steps listed below:<br /> <br /> 1) Ensure the appearance of an authorization UI in case a [https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html 401 HTTP response] is received. In load in the [https://github.com/servo/servo/blob/master/components/net/http_loader.rs http_loader.rs], immediately before attempting to process an HTTP redirection, the new [https://sourceforge.net/projects/tinyfiledialogs/ tinyfiledialogs] is made use of to make two prompts to pop up (for username and password), subsequently the request is restarted and the new authorization value present applied. If an authorization value was indeed present and the response is successful, the credentials are added to the authorization cache.<br /> <br /> 2) If the command-line option of the profile directory is present when the ResourceThread is instructed to exit, the data contained in the cookie_storage, hsts_list, and the new HTTP authorization cache is serialized. This serialized data is then written in separate files inside the profile directory.<br /> <br /> 3) Perform similar serialization upon shutdown for local_data in [https://doc.servo.org/src/net_traits/storage_thread.rs.html storage_thread.rs], which represents the LocalStorage API.<br /> <br /> 4) Check if the command-line option is present in the profile directory in the ResourceThreadconstructor and look for files that will contain serialized versions of the previous steps. If such files do exist, populate the appropriate fields with deserialized versions of the file’s contents.<br /> <br /> == '''Design Patterns''' ==<br /> 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]<br /> <br /> We do use a facade pattern by creating a safe RUST wrapper around the RUST FFI for the tinyfiledialogs library that we will use for the UI. We could have just called the FFI functions from servo, but instead we created a safe and simple interface to call the library functions.<br /> <br /> == '''Implementation / Design Decisions''' ==<br /> <br /> Here are some of the design decisions that we have made for implementing the steps mentioned in [http://wiki.expertiza.ncsu.edu/index.php/M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions#Scope Scope] :<br /> <br /> === Step 1 ===<br /> <br /> Objective: Make an authorization UI appear when a 401 HTTP response is received <br /> <br /> Using the tinyfiledialogs RUST FFI bindings that the team created in the initial steps we will create a UI for the user to enter his username and password when a 401 request is received for a basic HTTP authentication. We will first check if the status code of the http response is &quot;unauthorized&quot;. If the code is unauthorized we will display the UI for the user to enter his username and password. After the username and password are entered the request is restarted with the authentication header added. If the request is now successful we create a new authentication entry struct and place it into the Authentication hash map for future use.<br /> <br /> The UML Diagram for this implementation can be found [http://wiki.expertiza.ncsu.edu/index.php/M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions#UML_for_step_1 here]<br /> <br /> === Step 2 ===<br /> <br /> Objective: On shutdown serialize the data contained in cookie_storage, hsts_list, and the new HTTP authorization cache, and write the serialized data in separate files inside the profile directory.<br /> <br /> When a Resource Thread exits we will check if the opts structure located in opts.rs contains an entry for the command line option &quot;--profile dir&quot;. If the option is present when the Resource Thread exits we will open or create a file for each data set we are saving. After each file is opened or created we will serialize the data that corresponds to that file with the rust serialize library and save the serialized data to the file.<br /> <br /> The UML Diagram for this implementation can be found [http://wiki.expertiza.ncsu.edu/index.php/M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions#UML_for_step_2 here]<br /> <br /> === Step 3 ===<br /> <br /> Objective: On shutdown serialize the local_data in storage_thread.r<br /> <br /> This is similar to step 2 and some code re-use will be used. However, the difference between this step and step 2 is that the local data contained in storage_thread.rs will be the data that is being serialized and saved into the same directory.<br /> <br /> === Step 4 ===<br /> <br /> Objective: If the command line option for profile-dir is present then load the serialized data present in the directory that is given.<br /> <br /> When a resource thread is created we will check if the opts structure located in opts.rs contains a entry for the command line option &quot;--profile dir&quot;. If the option is present then the data from each file contained in the directory will be opened and deserialized using the serialize rust library. The data will then be placed in the appropriate fields. i.e (cookie_storage, hsts_lists, authorization_cache)<br /> <br /> The UML Diagram for this implementation can be found [http://wiki.expertiza.ncsu.edu/index.php/M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions#UML_for_step_4 here]<br /> <br /> =='''UML Diagrams'''==<br /> <br /> ==='''UML for step 1'''===<br /> <br /> [[File:517project.png ]]<br /> <br /> <br /> ==='''UML for step 2'''===<br /> <br /> [[File:STEP2.png ]]<br /> <br /> <br /> ==='''UML for step 4'''===<br /> <br /> [[File:STEP4.png ]]<br /> <br /> =='''Testing'''==<br /> <br /> ===Testing the new command line flag --profile-dir===<br /> <br /> Steps for Testing the new command line flag --profile-dir can be found [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2016_OSS_M1606#Testing_the_new_command_line_flag_--profile-dir here]<br /> <br /> === Unit Test for set authorization header if url does not have credentials ===<br /> <br /> Steps for Unit Tests for set authorization header if url does not have credentials can be found [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 here]<br /> <br /> === GUI test for the tinyfiledialogs lib ===<br /> <br /> Steps for GUI test for the tinyfiledialogs lib can be found [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2016_OSS_M1606#GUI_test_for_the_tinyfiledialogs_lib here ]<br /> <br /> =='''References'''==<br /> &lt;references/&gt;</div>

Mverma4 https://wiki.expertiza.ncsu.edu/index.php?title=M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions&diff=102179 2016-04-12T00:17:03Z

<p>Mverma4: /* Implementation / Design Decisions */</p> <hr /> <div>''' M1606: Implementing HTTP authorization UI and persistent sessions '''<br /> <br /> [https://en.wikipedia.org/wiki/Web_page Web pages] make use of [https://en.wikipedia.org/wiki/Session_(computer_science) 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.&lt;ref&gt; https://github.com/servo/servo/wiki/Persistent-sessions-student-project&lt;/ref&gt;<br /> <br /> With this project we aim to create the necessary infrastructure to support this.<br /> <br /> == '''Introduction''' ==<br /> <br /> <br /> === Servo ===<br /> <br /> <br /> [https://en.wikipedia.org/wiki/Servo_(layout_engine) 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.<br /> 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.&lt;ref&gt;https://en.wikipedia.org/wiki/Servo_(layout_engine)&lt;/ref&gt;<br /> <br /> === Rust ===<br /> <br /> [http://doc.rust-lang.org/book/README 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.<br /> 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.&lt;ref&gt;https://en.wikipedia.org/wiki/Rust_(programming_language)&lt;/ref&gt;<br /> <br /> == '''Previous Related Work''' ==<br /> <br /> '''A Wiki Page regarding this work can be found [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2016_OSS_M1606 here ]'''<br /> <br /> 1) Added a new command line flag &lt;code&gt; --profile-dir [path]&lt;/code&gt; that stores an optional directory path in the Opts struct in &lt;code&gt;opts.rs&lt;/code&gt;, creates the directory if it does not exist.<br /> <br /> [[File:Step2Wiki2spring16.jpg]]<br /> <br /> 2) Created [http://doc.rust-lang.org/book/ffi.html Rust FFI bindings] for the &lt;code&gt;[https://github.com/jdm/tinyfiledialogs tinyfiledialogs] &lt;/code&gt;library to allow calling the C methods from Servo.<br /> <br /> [[File:Step3-1Wiki2spring16.jpg]]<br /> <br /> [[File:Step3-2Wiki2spring16.jpg]]<br /> <br /> 3) In &lt;code&gt;resource_thread.rs&lt;/code&gt;, defined an HTTP authorization cache storage (username, password, URL) and instantiated it like the cookie_storage member (inside an &lt;code&gt;Arc&lt;Rwlock&lt;&gt;&gt;&lt;/code&gt; value, to enable sharing it between threads).<br /> <br /> [[File:Step4Wiki2spring16.jpg]]<br /> <br /> 4) In &lt;code&gt;modify_request_headers&lt;/code&gt; in &lt;code&gt;http_loader.rs&lt;/code&gt;, 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.<br /> <br /> [[File:Step5Wiki2spring16.jpg]]<br /> <br /> == '''Scope''' ==<br /> The scope of the project comprises of the 4 steps listed below:<br /> <br /> 1) Ensure the appearance of an authorization UI in case a [https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html 401 HTTP response] is received. In load in the [https://github.com/servo/servo/blob/master/components/net/http_loader.rs http_loader.rs], immediately before attempting to process an HTTP redirection, the new [https://sourceforge.net/projects/tinyfiledialogs/ tinyfiledialogs] is made use of to make two prompts to pop up (for username and password), subsequently the request is restarted and the new authorization value present applied. If an authorization value was indeed present and the response is successful, the credentials are added to the authorization cache.<br /> <br /> 2) If the command-line option of the profile directory is present when the ResourceThread is instructed to exit, the data contained in the cookie_storage, hsts_list, and the new HTTP authorization cache is serialized. This serialized data is then written in separate files inside the profile directory.<br /> <br /> 3) Perform similar serialization upon shutdown for local_data in [https://doc.servo.org/src/net_traits/storage_thread.rs.html storage_thread.rs], which represents the LocalStorage API.<br /> <br /> 4) Check if the command-line option is present in the profile directory in the ResourceThreadconstructor and look for files that will contain serialized versions of the previous steps. If such files do exist, populate the appropriate fields with deserialized versions of the file’s contents.<br /> <br /> == '''Design Patterns''' ==<br /> 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]<br /> <br /> We do use a facade pattern by creating a safe RUST wrapper around the RUST FFI for the tinyfiledialogs library that we will use for the UI. We could have just called the FFI functions from servo, but instead we created a safe and simple interface to call the library functions.<br /> <br /> == '''Implementation / Design Decisions''' ==<br /> <br /> Here are some of the design decisions that we have made for implementing the steps mentioned in [http://wiki.expertiza.ncsu.edu/index.php/M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions#Scope Scope] :<br /> <br /> === Step 1 ===<br /> <br /> Objective: Make an authorization UI appear when a 401 HTTP response is received <br /> <br /> Using the tinyfiledialogs RUST FFI bindings that the team created in the initial steps we will create a UI for the user to enter his username and password when a 401 request is received for a basic HTTP authentication. We will first check if the status code of the http response is &quot;unauthorized&quot;. If the code is unauthorized we will display the UI for the user to enter his username and password. After the username and password are entered the request is restarted with the authentication header added. If the request is now successful we create a new authentication entry struct and place it into the Authentication hash map for future use.<br /> <br /> The UML Diagram for this implementation can be found [http://wiki.expertiza.ncsu.edu/index.php/M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions#Scope here]<br /> <br /> === Step 2 ===<br /> <br /> Objective: On shutdown serialize the data contained in cookie_storage, hsts_list, and the new HTTP authorization cache, and write the serialized data in separate files inside the profile directory.<br /> <br /> When a Resource Thread exits we will check if the opts structure located in opts.rs contains an entry for the command line option &quot;--profile dir&quot;. If the option is present when the Resource Thread exits we will open or create a file for each data set we are saving. After each file is opened or created we will serialize the data that corresponds to that file with the rust serialize library and save the serialized data to the file.<br /> <br /> The UML Diagram for this implementation can be found [http://wiki.expertiza.ncsu.edu/index.php/M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions#Scope here]<br /> <br /> === Step 3 ===<br /> <br /> Objective: On shutdown serialize the local_data in storage_thread.r<br /> <br /> This is similar to step 2 and some code re-use will be used. However, the difference between this step and step 2 is that the local data contained in storage_thread.rs will be the data that is being serialized and saved into the same directory.<br /> <br /> === Step 4 ===<br /> <br /> Objective: If the command line option for profile-dir is present then load the serialized data present in the directory that is given.<br /> <br /> When a resource thread is created we will check if the opts structure located in opts.rs contains a entry for the command line option &quot;--profile dir&quot;. If the option is present then the data from each file contained in the directory will be opened and deserialized using the serialize rust library. The data will then be placed in the appropriate fields. i.e (cookie_storage, hsts_lists, authorization_cache)<br /> <br /> The UML Diagram for this implementation can be found [http://wiki.expertiza.ncsu.edu/index.php/M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions#Scope here]<br /> <br /> =='''UML Diagrams'''==<br /> <br /> ==='''UML for step 1'''===<br /> <br /> [[File:517project.png ]]<br /> <br /> <br /> ==='''UML for step 2'''===<br /> <br /> [[File:STEP2.png ]]<br /> <br /> <br /> ==='''UML for step 4'''===<br /> <br /> [[File:STEP4.png ]]<br /> <br /> =='''Testing'''==<br /> <br /> ===Testing the new command line flag --profile-dir===<br /> <br /> Steps for Testing the new command line flag --profile-dir can be found [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2016_OSS_M1606#Testing_the_new_command_line_flag_--profile-dir here]<br /> <br /> === Unit Test for set authorization header if url does not have credentials ===<br /> <br /> Steps for Unit Tests for set authorization header if url does not have credentials can be found [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 here]<br /> <br /> === GUI test for the tinyfiledialogs lib ===<br /> <br /> Steps for GUI test for the tinyfiledialogs lib can be found [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2016_OSS_M1606#GUI_test_for_the_tinyfiledialogs_lib here ]<br /> <br /> =='''References'''==<br /> &lt;references/&gt;</div>

Mverma4 https://wiki.expertiza.ncsu.edu/index.php?title=M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions&diff=102178 2016-04-12T00:14:12Z

<p>Mverma4: /* UML for step 4 */</p> <hr /> <div>''' M1606: Implementing HTTP authorization UI and persistent sessions '''<br /> <br /> [https://en.wikipedia.org/wiki/Web_page Web pages] make use of [https://en.wikipedia.org/wiki/Session_(computer_science) 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.&lt;ref&gt; https://github.com/servo/servo/wiki/Persistent-sessions-student-project&lt;/ref&gt;<br /> <br /> With this project we aim to create the necessary infrastructure to support this.<br /> <br /> == '''Introduction''' ==<br /> <br /> <br /> === Servo ===<br /> <br /> <br /> [https://en.wikipedia.org/wiki/Servo_(layout_engine) 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.<br /> 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.&lt;ref&gt;https://en.wikipedia.org/wiki/Servo_(layout_engine)&lt;/ref&gt;<br /> <br /> === Rust ===<br /> <br /> [http://doc.rust-lang.org/book/README 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.<br /> 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.&lt;ref&gt;https://en.wikipedia.org/wiki/Rust_(programming_language)&lt;/ref&gt;<br /> <br /> == '''Previous Related Work''' ==<br /> <br /> '''A Wiki Page regarding this work can be found [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2016_OSS_M1606 here ]'''<br /> <br /> 1) Added a new command line flag &lt;code&gt; --profile-dir [path]&lt;/code&gt; that stores an optional directory path in the Opts struct in &lt;code&gt;opts.rs&lt;/code&gt;, creates the directory if it does not exist.<br /> <br /> [[File:Step2Wiki2spring16.jpg]]<br /> <br /> 2) Created [http://doc.rust-lang.org/book/ffi.html Rust FFI bindings] for the &lt;code&gt;[https://github.com/jdm/tinyfiledialogs tinyfiledialogs] &lt;/code&gt;library to allow calling the C methods from Servo.<br /> <br /> [[File:Step3-1Wiki2spring16.jpg]]<br /> <br /> [[File:Step3-2Wiki2spring16.jpg]]<br /> <br /> 3) In &lt;code&gt;resource_thread.rs&lt;/code&gt;, defined an HTTP authorization cache storage (username, password, URL) and instantiated it like the cookie_storage member (inside an &lt;code&gt;Arc&lt;Rwlock&lt;&gt;&gt;&lt;/code&gt; value, to enable sharing it between threads).<br /> <br /> [[File:Step4Wiki2spring16.jpg]]<br /> <br /> 4) In &lt;code&gt;modify_request_headers&lt;/code&gt; in &lt;code&gt;http_loader.rs&lt;/code&gt;, 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.<br /> <br /> [[File:Step5Wiki2spring16.jpg]]<br /> <br /> == '''Scope''' ==<br /> The scope of the project comprises of the 4 steps listed below:<br /> <br /> 1) Ensure the appearance of an authorization UI in case a [https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html 401 HTTP response] is received. In load in the [https://github.com/servo/servo/blob/master/components/net/http_loader.rs http_loader.rs], immediately before attempting to process an HTTP redirection, the new [https://sourceforge.net/projects/tinyfiledialogs/ tinyfiledialogs] is made use of to make two prompts to pop up (for username and password), subsequently the request is restarted and the new authorization value present applied. If an authorization value was indeed present and the response is successful, the credentials are added to the authorization cache.<br /> <br /> 2) If the command-line option of the profile directory is present when the ResourceThread is instructed to exit, the data contained in the cookie_storage, hsts_list, and the new HTTP authorization cache is serialized. This serialized data is then written in separate files inside the profile directory.<br /> <br /> 3) Perform similar serialization upon shutdown for local_data in [https://doc.servo.org/src/net_traits/storage_thread.rs.html storage_thread.rs], which represents the LocalStorage API.<br /> <br /> 4) Check if the command-line option is present in the profile directory in the ResourceThreadconstructor and look for files that will contain serialized versions of the previous steps. If such files do exist, populate the appropriate fields with deserialized versions of the file’s contents.<br /> <br /> == '''Design Patterns''' ==<br /> 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]<br /> <br /> We do use a facade pattern by creating a safe RUST wrapper around the RUST FFI for the tinyfiledialogs library that we will use for the UI. We could have just called the FFI functions from servo, but instead we created a safe and simple interface to call the library functions.<br /> <br /> == '''Implementation / Design Decisions''' ==<br /> <br /> Here are some of the design decisions that we have made for implementing the steps mentioned in [http://wiki.expertiza.ncsu.edu/index.php/M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions#Scope Scope] :<br /> <br /> === Step 1 ===<br /> <br /> Objective: Make an authorization UI appear when a 401 HTTP response is received <br /> <br /> Using the tinyfiledialogs RUST FFI bindings that the team created in the initial steps we will create a UI for the user to enter his username and password when a 401 request is received for a basic HTTP authentication. We will first check if the status code of the http response is &quot;unauthorized&quot;. If the code is unauthorized we will display the UI for the user to enter his username and password. After the username and password are entered the request is restarted with the authentication header added. If the request is now successful we create a new authentication entry struct and place it into the Authentication hash map for future use.<br /> <br /> === Step 2 ===<br /> <br /> Objective: On shutdown serialize the data contained in cookie_storage, hsts_list, and the new HTTP authorization cache, and write the serialized data in separate files inside the profile directory.<br /> <br /> When a Resource Thread exits we will check if the opts structure located in opts.rs contains an entry for the command line option &quot;--profile dir&quot;. If the option is present when the Resource Thread exits we will open or create a file for each data set we are saving. After each file is opened or created we will serialize the data that corresponds to that file with the rust serialize library and save the serialized data to the file.<br /> <br /> === Step 3 ===<br /> <br /> Objective: On shutdown serialize the local_data in storage_thread.r<br /> <br /> This is similar to step 2 and some code re-use will be used. However, the difference between this step and step 2 is that the local data contained in storage_thread.rs will be the data that is being serialized and saved into the same directory.<br /> <br /> === Step 4 ===<br /> <br /> Objective: If the command line option for profile-dir is present then load the serialized data present in the directory that is given.<br /> <br /> When a resource thread is created we will check if the opts structure located in opts.rs contains a entry for the command line option &quot;--profile dir&quot;. If the option is present then the data from each file contained in the directory will be opened and deserialized using the serialize rust library. The data will then be placed in the appropriate fields. i.e (cookie_storage, hsts_lists, authorization_cache)<br /> <br /> =='''UML Diagrams'''==<br /> <br /> ==='''UML for step 1'''===<br /> <br /> [[File:517project.png ]]<br /> <br /> <br /> ==='''UML for step 2'''===<br /> <br /> [[File:STEP2.png ]]<br /> <br /> <br /> ==='''UML for step 4'''===<br /> <br /> [[File:STEP4.png ]]<br /> <br /> =='''Testing'''==<br /> <br /> ===Testing the new command line flag --profile-dir===<br /> <br /> Steps for Testing the new command line flag --profile-dir can be found [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2016_OSS_M1606#Testing_the_new_command_line_flag_--profile-dir here]<br /> <br /> === Unit Test for set authorization header if url does not have credentials ===<br /> <br /> Steps for Unit Tests for set authorization header if url does not have credentials can be found [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 here]<br /> <br /> === GUI test for the tinyfiledialogs lib ===<br /> <br /> Steps for GUI test for the tinyfiledialogs lib can be found [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2016_OSS_M1606#GUI_test_for_the_tinyfiledialogs_lib here ]<br /> <br /> =='''References'''==<br /> &lt;references/&gt;</div>

Mverma4 https://wiki.expertiza.ncsu.edu/index.php?title=File:STEP4.png&diff=102177 2016-04-12T00:13:21Z

<p>Mverma4: </p> <hr /> <div></div>

Mverma4 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016&diff=102176 2016-04-12T00:05:58Z

<p>Mverma4: /* Final Project Design Document */</p> <hr /> <div>==Writing Assignment 1==<br /> *[[CSC/ECE 517 Spring 2016/Active Job]]<br /> <br /> <br /> ==Calibration Assignment Submissions==<br /> *[[Calibration Assignment Submission (OmniAuth)]]<br /> *[[Calibration Assignment Submission (Patch_verb)]]<br /> <br /> ==Writing Assignment 2==<br /> *[[CSC/ECE 517 Spring 2016/Mozilla Implement HTML5 form validation]]<br /> <br /> *[[CSC/ECE_517_Spring_2016/Mozilla Conforming Image Loading to HTML 5 Specs]]<br /> <br /> *[[CSC/ECE 517 Spring 2016/Functional Tests for Questionnaire Controller]]<br /> <br /> *[[CSC/ECE 517 Spring 2016 / Expertiza Self-Review Feature]]<br /> <br /> *[[CSC/ECE 517 Spring 2016/Refactor different question types from quiz feature]]<br /> <br /> *[[CSC/ECE 517 Spring 2016/Implement private browsing]]<br /> <br /> *[[CSC/ECE 517 Spring 2016/Write automated tests for WebDriver]]<br /> <br /> *[[CSC/ECE 517 Spring 2016/Refactor sign_up_sheet_controller.rb and sign_up_topic.rb]]<br /> <br /> *[[CSC/ECE 517 Spring 2016/Implement Common Parts of the CSSOM API]]<br /> <br /> *[[CSC/ECE 517 Spring 2016/Functional tests for assignment creation function]]<br /> <br /> *[[CSC/ECE 517 Spring 2016/E1604. Functional tests for Calibration function]]<br /> <br /> *[[CSC/ECE 517 Spring 2016/Refactor and write unit tests for question type.rb]]<br /> <br /> *[[CSC/ECE 517 Spring 2016/Refactor response controller]]<br /> <br /> *[[CSC/ECE_517_Spring_2016_OSS_M1606]]<br /> <br /> *[[CSC/ECE_517_Spring_2016/OSS_E1601]]<br /> <br /> ==Final Project Design Document==<br /> *[[CSC/ECE 517 Spring 2016 M1601 Implement HTML5 form validation]]<br /> *[[CSC/ECE 517 Spring 2016 M1602 Make image loads conform with the spec]]<br /> *[[CSC/ECE 517 Spring 2016 E1624 Compose functional tests for Suggest topics of student functionality ]]<br /> *[[CSC/ECE 517 Spring 2016 E1631 Team-based reviewing]]<br /> *[[CSC/ECE 517 Spring 2016 E1628 Visualization]]<br /> *[[CSC/ECE 517 Spring 2016 E1625 Show confidence ratings for grade based on reputations of reviewers]]<br /> *[[CSC/ECE 517 Spring 2016 E1629 Performance improvement for Course &amp; Assignment Listing]]<br /> *[[CSC/ECE 517 Spring 2016 M1603 Implement Common Parts of the CSSOM API]]<br /> *[[M1606: Implementing HTTP authorization UI and persistent sessions]]</div>

Mverma4 https://wiki.expertiza.ncsu.edu/index.php?title=M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions&diff=102175 2016-04-12T00:04:09Z

<p>Mverma4: /* UML Diagrams */</p> <hr /> <div>''' M1606: Implementing HTTP authorization UI and persistent sessions '''<br /> <br /> [https://en.wikipedia.org/wiki/Web_page Web pages] make use of [https://en.wikipedia.org/wiki/Session_(computer_science) 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.&lt;ref&gt; https://github.com/servo/servo/wiki/Persistent-sessions-student-project&lt;/ref&gt;<br /> <br /> With this project we aim to create the necessary infrastructure to support this.<br /> <br /> == '''Introduction''' ==<br /> <br /> <br /> === Servo ===<br /> <br /> <br /> [https://en.wikipedia.org/wiki/Servo_(layout_engine) 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.<br /> 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.&lt;ref&gt;https://en.wikipedia.org/wiki/Servo_(layout_engine)&lt;/ref&gt;<br /> <br /> === Rust ===<br /> <br /> [http://doc.rust-lang.org/book/README 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.<br /> 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.&lt;ref&gt;https://en.wikipedia.org/wiki/Rust_(programming_language)&lt;/ref&gt;<br /> <br /> == '''Previous Related Work''' ==<br /> <br /> '''A Wiki Page regarding this work can be found [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2016_OSS_M1606 here ]'''<br /> <br /> 1) Added a new command line flag &lt;code&gt; --profile-dir [path]&lt;/code&gt; that stores an optional directory path in the Opts struct in &lt;code&gt;opts.rs&lt;/code&gt;, creates the directory if it does not exist.<br /> <br /> [[File:Step2Wiki2spring16.jpg]]<br /> <br /> 2) Created [http://doc.rust-lang.org/book/ffi.html Rust FFI bindings] for the &lt;code&gt;[https://github.com/jdm/tinyfiledialogs tinyfiledialogs] &lt;/code&gt;library to allow calling the C methods from Servo.<br /> <br /> [[File:Step3-1Wiki2spring16.jpg]]<br /> <br /> [[File:Step3-2Wiki2spring16.jpg]]<br /> <br /> 3) In &lt;code&gt;resource_thread.rs&lt;/code&gt;, defined an HTTP authorization cache storage (username, password, URL) and instantiated it like the cookie_storage member (inside an &lt;code&gt;Arc&lt;Rwlock&lt;&gt;&gt;&lt;/code&gt; value, to enable sharing it between threads).<br /> <br /> [[File:Step4Wiki2spring16.jpg]]<br /> <br /> 4) In &lt;code&gt;modify_request_headers&lt;/code&gt; in &lt;code&gt;http_loader.rs&lt;/code&gt;, 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.<br /> <br /> [[File:Step5Wiki2spring16.jpg]]<br /> <br /> == '''Scope''' ==<br /> The scope of the project comprises of the 4 steps listed below:<br /> <br /> 1) Ensure the appearance of an authorization UI in case a [https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html 401 HTTP response] is received. In load in the [https://github.com/servo/servo/blob/master/components/net/http_loader.rs http_loader.rs], immediately before attempting to process an HTTP redirection, the new [https://sourceforge.net/projects/tinyfiledialogs/ tinyfiledialogs] is made use of to make two prompts to pop up (for username and password), subsequently the request is restarted and the new authorization value present applied. If an authorization value was indeed present and the response is successful, the credentials are added to the authorization cache.<br /> <br /> 2) If the command-line option of the profile directory is present when the ResourceThread is instructed to exit, the data contained in the cookie_storage, hsts_list, and the new HTTP authorization cache is serialized. This serialized data is then written in separate files inside the profile directory.<br /> <br /> 3) Perform similar serialization upon shutdown for local_data in [https://doc.servo.org/src/net_traits/storage_thread.rs.html storage_thread.rs], which represents the LocalStorage API.<br /> <br /> 4) Check if the command-line option is present in the profile directory in the ResourceThreadconstructor and look for files that will contain serialized versions of the previous steps. If such files do exist, populate the appropriate fields with deserialized versions of the file’s contents.<br /> <br /> == '''Design Patterns''' ==<br /> 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]<br /> <br /> We do use a facade pattern by creating a safe RUST wrapper around the RUST FFI for the tinyfiledialogs library that we will use for the UI. We could have just called the FFI functions from servo, but instead we created a safe and simple interface to call the library functions.<br /> <br /> == '''Implementation / Design Decisions''' ==<br /> <br /> Here are some of the design decisions that we have made for implementing the steps mentioned in [http://wiki.expertiza.ncsu.edu/index.php/M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions#Scope Scope] :<br /> <br /> === Step 1 ===<br /> <br /> Objective: Make an authorization UI appear when a 401 HTTP response is received <br /> <br /> Using the tinyfiledialogs RUST FFI bindings that the team created in the initial steps we will create a UI for the user to enter his username and password when a 401 request is received for a basic HTTP authentication. We will first check if the status code of the http response is &quot;unauthorized&quot;. If the code is unauthorized we will display the UI for the user to enter his username and password. After the username and password are entered the request is restarted with the authentication header added. If the request is now successful we create a new authentication entry struct and place it into the Authentication hash map for future use.<br /> <br /> === Step 2 ===<br /> <br /> Objective: On shutdown serialize the data contained in cookie_storage, hsts_list, and the new HTTP authorization cache, and write the serialized data in separate files inside the profile directory.<br /> <br /> When a Resource Thread exits we will check if the opts structure located in opts.rs contains an entry for the command line option &quot;--profile dir&quot;. If the option is present when the Resource Thread exits we will open or create a file for each data set we are saving. After each file is opened or created we will serialize the data that corresponds to that file with the rust serialize library and save the serialized data to the file.<br /> <br /> === Step 3 ===<br /> <br /> Objective: On shutdown serialize the local_data in storage_thread.r<br /> <br /> This is similar to step 2 and some code re-use will be used. However, the difference between this step and step 2 is that the local data contained in storage_thread.rs will be the data that is being serialized and saved into the same directory.<br /> <br /> === Step 4 ===<br /> <br /> Objective: If the command line option for profile-dir is present then load the serialized data present in the directory that is given.<br /> <br /> When a resource thread is created we will check if the opts structure located in opts.rs contains a entry for the command line option &quot;--profile dir&quot;. If the option is present then the data from each file contained in the directory will be opened and deserialized using the serialize rust library. The data will then be placed in the appropriate fields. i.e (cookie_storage, hsts_lists, authorization_cache)<br /> <br /> =='''UML Diagrams'''==<br /> <br /> ==='''UML for step 1'''===<br /> <br /> [[File:517project.png ]]<br /> <br /> <br /> ==='''UML for step 2'''===<br /> <br /> [[File:STEP2.png ]]<br /> <br /> <br /> ==='''UML for step 4'''===<br /> <br /> [[File:517project.png ]]<br /> <br /> =='''Testing'''==<br /> <br /> ===Testing the new command line flag --profile-dir===<br /> <br /> Steps for Testing the new command line flag --profile-dir can be found [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2016_OSS_M1606#Testing_the_new_command_line_flag_--profile-dir here]<br /> <br /> === Unit Test for set authorization header if url does not have credentials ===<br /> <br /> Steps for Unit Tests for set authorization header if url does not have credentials can be found [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 here]<br /> <br /> === GUI test for the tinyfiledialogs lib ===<br /> <br /> Steps for GUI test for the tinyfiledialogs lib can be found [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2016_OSS_M1606#GUI_test_for_the_tinyfiledialogs_lib here ]<br /> <br /> =='''References'''==<br /> &lt;references/&gt;</div>

Mverma4 https://wiki.expertiza.ncsu.edu/index.php?title=File:STEP2.png&diff=102174 2016-04-12T00:02:40Z

<p>Mverma4: </p> <hr /> <div></div>

Mverma4 https://wiki.expertiza.ncsu.edu/index.php?title=File:Step_2.png&diff=102154 2016-04-11T22:20:51Z

<p>Mverma4: uploaded a new version of &amp;quot;File:Step 2.png&amp;quot;</p> <hr /> <div></div>

Mverma4 https://wiki.expertiza.ncsu.edu/index.php?title=File:Step_3.png&diff=102153 2016-04-11T22:19:58Z

<p>Mverma4: </p> <hr /> <div></div>

Mverma4 https://wiki.expertiza.ncsu.edu/index.php?title=File:Step_2.png&diff=102152 2016-04-11T22:19:27Z

<p>Mverma4: </p> <hr /> <div></div>

Mverma4 https://wiki.expertiza.ncsu.edu/index.php?title=M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions&diff=101808 2016-04-04T18:06:15Z

<p>Mverma4: /* Previous Work */</p> <hr /> <div>''' M1606: Implementing HTTP authorization UI and persistent sessions '''<br /> <br /> [https://en.wikipedia.org/wiki/Web_page Web pages] make use of [https://en.wikipedia.org/wiki/Session_(computer_science) 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.&lt;ref&gt; https://github.com/servo/servo/wiki/Persistent-sessions-student-project&lt;/ref&gt;<br /> <br /> With this project we aim to create the necessary infrastructure to support this.<br /> <br /> == '''Introduction''' ==<br /> <br /> <br /> === Servo ===<br /> <br /> <br /> [https://en.wikipedia.org/wiki/Servo_(layout_engine) 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.<br /> 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.&lt;ref&gt;https://en.wikipedia.org/wiki/Servo_(layout_engine)&lt;/ref&gt;<br /> <br /> === Rust ===<br /> <br /> [http://doc.rust-lang.org/book/README 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.<br /> 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.&lt;ref&gt;https://en.wikipedia.org/wiki/Rust_(programming_language)&lt;/ref&gt;<br /> <br /> == '''Previous Related Work''' ==<br /> <br /> '''A Wiki Page regarding this work can be found [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2016_OSS_M1606 here ]'''<br /> <br /> 1) Added a new command line flag &lt;code&gt; --profile-dir [path]&lt;/code&gt; that stores an optional directory path in the Opts struct in &lt;code&gt;opts.rs&lt;/code&gt;, creates the directory if it does not exist.<br /> <br /> [[File:Step2Wiki2spring16.jpg]]<br /> <br /> 2) Created [http://doc.rust-lang.org/book/ffi.html Rust FFI bindings] for the &lt;code&gt;[https://github.com/jdm/tinyfiledialogs tinyfiledialogs] &lt;/code&gt;library to allow calling the C methods from Servo.<br /> <br /> [[File:Step3-1Wiki2spring16.jpg]]<br /> <br /> [[File:Step3-2Wiki2spring16.jpg]]<br /> <br /> 3) In &lt;code&gt;resource_thread.rs&lt;/code&gt;, defined an HTTP authorization cache storage (username, password, URL) and instantiated it like the cookie_storage member (inside an &lt;code&gt;Arc&lt;Rwlock&lt;&gt;&gt;&lt;/code&gt; value, to enable sharing it between threads).<br /> <br /> [[File:Step4Wiki2spring16.jpg]]<br /> <br /> 4) In &lt;code&gt;modify_request_headers&lt;/code&gt; in &lt;code&gt;http_loader.rs&lt;/code&gt;, 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.<br /> <br /> [[File:Step5Wiki2spring16.jpg]]<br /> <br /> == '''Scope''' == <br /> <br /> The scope of this project is to:<br /> <br /> 1)<br /> <br /> 2)<br /> <br /> 3)<br /> <br /> 4)<br /> <br /> == '''Design Patterns''' ==<br /> 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]<br /> <br /> == '''Implementation / Design Decisions''' ==<br /> <br /> Here are some of the design decisions that we have made for implementing the steps mentioned in [http://wiki.expertiza.ncsu.edu/index.php/M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions#Scope Scope] :<br /> <br /> === Step 1 ===<br /> <br /> Objective:<br /> <br /> === Step 2 ===<br /> <br /> Objective: <br /> <br /> === Step 3 ===<br /> <br /> Objective: <br /> <br /> === Step 4 ===<br /> <br /> Objective:<br /> <br /> =='''Testing'''==<br /> <br /> ===Testing the new command line flag --profile-dir===<br /> <br /> Steps for Testing the new command line flag --profile-dir can be found [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2016_OSS_M1606#Testing_the_new_command_line_flag_--profile-dir here]<br /> <br /> === Unit Test for set authorization header if url does not have credentials ===<br /> <br /> Steps for Unit Tests for set authorization header if url does not have credentials can be found [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 here]<br /> <br /> === GUI test for the tinyfiledialogs lib ===<br /> <br /> Steps for GUI test for the tinyfiledialogs lib can be found [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2016_OSS_M1606#GUI_test_for_the_tinyfiledialogs_lib here ]<br /> <br /> =='''References'''==<br /> &lt;references/&gt;</div>

Mverma4 https://wiki.expertiza.ncsu.edu/index.php?title=M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions&diff=101807 2016-04-04T17:54:10Z

<p>Mverma4: </p> <hr /> <div>''' M1606: Implementing HTTP authorization UI and persistent sessions '''<br /> <br /> [https://en.wikipedia.org/wiki/Web_page Web pages] make use of [https://en.wikipedia.org/wiki/Session_(computer_science) 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.&lt;ref&gt; https://github.com/servo/servo/wiki/Persistent-sessions-student-project&lt;/ref&gt;<br /> <br /> With this project we aim to create the necessary infrastructure to support this.<br /> <br /> == '''Introduction''' ==<br /> <br /> <br /> === Servo ===<br /> <br /> <br /> [https://en.wikipedia.org/wiki/Servo_(layout_engine) 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.<br /> 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.&lt;ref&gt;https://en.wikipedia.org/wiki/Servo_(layout_engine)&lt;/ref&gt;<br /> <br /> === Rust ===<br /> <br /> [http://doc.rust-lang.org/book/README 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.<br /> 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.&lt;ref&gt;https://en.wikipedia.org/wiki/Rust_(programming_language)&lt;/ref&gt;<br /> <br /> == '''Previous Work''' ==<br /> <br /> '''A Wiki Page regarding this work can be found [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2016_OSS_M1606 here ]'''<br /> <br /> 1) Added a new command line flag &lt;code&gt; --profile-dir [path]&lt;/code&gt; that stores an optional directory path in the Opts struct in &lt;code&gt;opts.rs&lt;/code&gt;, creates the directory if it does not exist.<br /> <br /> [[File:Step2Wiki2spring16.jpg]]<br /> <br /> 2) Created [http://doc.rust-lang.org/book/ffi.html Rust FFI bindings] for the &lt;code&gt;[https://github.com/jdm/tinyfiledialogs tinyfiledialogs] &lt;/code&gt;library to allow calling the C methods from Servo.<br /> <br /> [[File:Step3-1Wiki2spring16.jpg]]<br /> <br /> [[File:Step3-2Wiki2spring16.jpg]]<br /> <br /> 3) In &lt;code&gt;resource_thread.rs&lt;/code&gt;, defined an HTTP authorization cache storage (username, password, URL) and instantiated it like the cookie_storage member (inside an &lt;code&gt;Arc&lt;Rwlock&lt;&gt;&gt;&lt;/code&gt; value, to enable sharing it between threads).<br /> <br /> [[File:Step4Wiki2spring16.jpg]]<br /> <br /> 4) In &lt;code&gt;modify_request_headers&lt;/code&gt; in &lt;code&gt;http_loader.rs&lt;/code&gt;, 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.<br /> <br /> [[File:Step5Wiki2spring16.jpg]]<br /> <br /> == '''Scope''' == <br /> <br /> The scope of this project is to:<br /> <br /> 1)<br /> <br /> 2)<br /> <br /> 3)<br /> <br /> 4)<br /> <br /> == '''Design Patterns''' ==<br /> 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]<br /> <br /> == '''Implementation / Design Decisions''' ==<br /> <br /> Here are some of the design decisions that we have made for implementing the steps mentioned in [http://wiki.expertiza.ncsu.edu/index.php/M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions#Scope Scope] :<br /> <br /> === Step 1 ===<br /> <br /> Objective:<br /> <br /> === Step 2 ===<br /> <br /> Objective: <br /> <br /> === Step 3 ===<br /> <br /> Objective: <br /> <br /> === Step 4 ===<br /> <br /> Objective:<br /> <br /> =='''Testing'''==<br /> <br /> ===Testing the new command line flag --profile-dir===<br /> <br /> Steps for Testing the new command line flag --profile-dir can be found [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2016_OSS_M1606#Testing_the_new_command_line_flag_--profile-dir here]<br /> <br /> === Unit Test for set authorization header if url does not have credentials ===<br /> <br /> Steps for Unit Tests for set authorization header if url does not have credentials can be found [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 here]<br /> <br /> === GUI test for the tinyfiledialogs lib ===<br /> <br /> Steps for GUI test for the tinyfiledialogs lib can be found [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2016_OSS_M1606#GUI_test_for_the_tinyfiledialogs_lib here ]<br /> <br /> =='''References'''==<br /> &lt;references/&gt;</div>

Mverma4 https://wiki.expertiza.ncsu.edu/index.php?title=M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions&diff=101806 2016-04-04T17:53:25Z

<p>Mverma4: /* Previous Work */</p> <hr /> <div>''' M1606: Implementing HTTP authorization UI and persistent sessions '''<br /> <br /> [https://en.wikipedia.org/wiki/Web_page Web pages] make use of [https://en.wikipedia.org/wiki/Session_(computer_science) 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.&lt;ref&gt; https://github.com/servo/servo/wiki/Persistent-sessions-student-project&lt;/ref&gt;<br /> <br /> With this project we aim to create the necessary infrastructure to support this.<br /> <br /> == '''Introduction''' ==<br /> <br /> <br /> === Servo ===<br /> <br /> <br /> [https://en.wikipedia.org/wiki/Servo_(layout_engine) 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.<br /> 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.&lt;ref&gt;https://en.wikipedia.org/wiki/Servo_(layout_engine)&lt;/ref&gt;<br /> <br /> === Rust ===<br /> <br /> [http://doc.rust-lang.org/book/README 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.<br /> 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.&lt;ref&gt;https://en.wikipedia.org/wiki/Rust_(programming_language)&lt;/ref&gt;<br /> <br /> == '''Previous Work''' ==<br /> <br /> '''A Wiki Page regarding this work can be found [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2016_OSS_M1606 here ]'''<br /> <br /> 1) Added a new command line flag &lt;code&gt; --profile-dir [path]&lt;/code&gt; that stores an optional directory path in the Opts struct in &lt;code&gt;opts.rs&lt;/code&gt;, creates the directory if it does not exist.<br /> <br /> [[File:Step2Wiki2spring16.jpg]]<br /> <br /> 2) Created [http://doc.rust-lang.org/book/ffi.html Rust FFI bindings] for the &lt;code&gt;[https://github.com/jdm/tinyfiledialogs tinyfiledialogs] &lt;/code&gt;library to allow calling the C methods from Servo.<br /> <br /> [[File:Step3-1Wiki2spring16.jpg]]<br /> <br /> [[File:Step3-2Wiki2spring16.jpg]]<br /> <br /> 3) In &lt;code&gt;resource_thread.rs&lt;/code&gt;, defined an HTTP authorization cache storage (username, password, URL) and instantiated it like the cookie_storage member (inside an &lt;code&gt;Arc&lt;Rwlock&lt;&gt;&gt;&lt;/code&gt; value, to enable sharing it between threads).<br /> <br /> [[File:Step4Wiki2spring16.jpg]]<br /> <br /> 4) In &lt;code&gt;modify_request_headers&lt;/code&gt; in &lt;code&gt;http_loader.rs&lt;/code&gt;, 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.<br /> <br /> [[File:Step5Wiki2spring16.jpg]]<br /> <br /> == '''Scope''' == <br /> <br /> The scope of this project is to:<br /> <br /> 1)<br /> <br /> 2)<br /> <br /> 3)<br /> <br /> 4)<br /> <br /> == '''Design Patterns''' ==<br /> 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]<br /> <br /> == '''Implementation / Design Decisions''' ==<br /> <br /> Here are some of the design decisions that we have made for implementing the steps mentioned in [http://wiki.expertiza.ncsu.edu/index.php/M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions#Scope Scope] :<br /> <br /> === Step 1 ===<br /> <br /> Objective:<br /> <br /> === Step 2 ===<br /> <br /> Objective: <br /> <br /> === Step 3 ===<br /> <br /> Objective: <br /> <br /> === Step 4 ===<br /> <br /> Objective:<br /> <br /> =='''Testing'''==<br /> <br /> ===Testing the new command line flag --profile-dir===<br /> <br /> Steps for Testing the new command line flag --profile-dir can be found [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2016_OSS_M1606#Testing_the_new_command_line_flag_--profile-dir here]<br /> <br /> === Unit Test for set authorization header if url does not have credentials ===<br /> <br /> Steps for Unit Tests for set authorization header if url does not have credentials can be found [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 here]<br /> <br /> === GUI test for the tinyfiledialogs lib ===<br /> <br /> Steps for GUI test for the tinyfiledialogs lib can be found [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2016_OSS_M1606#GUI_test_for_the_tinyfiledialogs_lib here ]<br /> <br /> == '''Conclusion''' ==<br /> <br /> =='''References'''==<br /> &lt;references/&gt;</div>

Mverma4 https://wiki.expertiza.ncsu.edu/index.php?title=M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions&diff=101803 2016-04-04T17:44:14Z

<p>Mverma4: /* Testing */</p> <hr /> <div>''' M1606: Implementing HTTP authorization UI and persistent sessions '''<br /> <br /> [https://en.wikipedia.org/wiki/Web_page Web pages] make use of [https://en.wikipedia.org/wiki/Session_(computer_science) 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.&lt;ref&gt; https://github.com/servo/servo/wiki/Persistent-sessions-student-project&lt;/ref&gt;<br /> <br /> With this project we aim to create the necessary infrastructure to support this.<br /> <br /> == '''Introduction''' ==<br /> <br /> <br /> === Servo ===<br /> <br /> <br /> [https://en.wikipedia.org/wiki/Servo_(layout_engine) 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.<br /> 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.&lt;ref&gt;https://en.wikipedia.org/wiki/Servo_(layout_engine)&lt;/ref&gt;<br /> <br /> === Rust ===<br /> <br /> [http://doc.rust-lang.org/book/README 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.<br /> 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.&lt;ref&gt;https://en.wikipedia.org/wiki/Rust_(programming_language)&lt;/ref&gt;<br /> <br /> == '''Previous Work''' ==<br /> <br /> 1) Added a new command line flag &lt;code&gt; --profile-dir [path]&lt;/code&gt; that stores an optional directory path in the Opts struct in &lt;code&gt;opts.rs&lt;/code&gt;, creates the directory if it does not exist.<br /> <br /> 2) Created [http://doc.rust-lang.org/book/ffi.html Rust FFI bindings] for the &lt;code&gt;[https://github.com/jdm/tinyfiledialogs tinyfiledialogs] &lt;/code&gt;library to allow calling the C methods from Servo.<br /> <br /> 3) In &lt;code&gt;resource_thread.rs&lt;/code&gt;, defined an HTTP authorization cache storage (username, password, URL) and instantiated it like the cookie_storage member (inside an &lt;code&gt;Arc&lt;Rwlock&lt;&gt;&gt;&lt;/code&gt; value, to enable sharing it between threads).<br /> <br /> 4) In &lt;code&gt;modify_request_headers&lt;/code&gt; in &lt;code&gt;http_loader.rs&lt;/code&gt;, 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.<br /> <br /> '''A Wiki Page regarding this work can be found [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2016_OSS_M1606 here ]<br /> '''<br /> <br /> == '''Scope''' == <br /> <br /> The scope of this project is to:<br /> <br /> 1)<br /> <br /> 2)<br /> <br /> 3)<br /> <br /> 4)<br /> <br /> == '''Design Patterns''' ==<br /> 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]<br /> <br /> == '''Implementation / Design Decisions''' ==<br /> <br /> Here are some of the design decisions that we have made for implementing the steps mentioned in [http://wiki.expertiza.ncsu.edu/index.php/M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions#Scope Scope] :<br /> <br /> === Step 1 ===<br /> <br /> Objective:<br /> <br /> === Step 2 ===<br /> <br /> Objective: <br /> <br /> === Step 3 ===<br /> <br /> Objective: <br /> <br /> === Step 4 ===<br /> <br /> Objective:<br /> <br /> =='''Testing'''==<br /> <br /> ===Testing the new command line flag --profile-dir===<br /> <br /> Steps for Testing the new command line flag --profile-dir can be found [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2016_OSS_M1606#Testing_the_new_command_line_flag_--profile-dir here]<br /> <br /> === Unit Test for set authorization header if url does not have credentials ===<br /> <br /> Steps for Unit Tests for set authorization header if url does not have credentials can be found [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 here]<br /> <br /> === GUI test for the tinyfiledialogs lib ===<br /> <br /> Steps for GUI test for the tinyfiledialogs lib can be found [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2016_OSS_M1606#GUI_test_for_the_tinyfiledialogs_lib here ]<br /> <br /> == '''Conclusion''' ==<br /> <br /> =='''References'''==<br /> &lt;references/&gt;</div>

Mverma4 https://wiki.expertiza.ncsu.edu/index.php?title=M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions&diff=101801 2016-04-04T17:33:38Z

<p>Mverma4: </p> <hr /> <div>''' M1606: Implementing HTTP authorization UI and persistent sessions '''<br /> <br /> [https://en.wikipedia.org/wiki/Web_page Web pages] make use of [https://en.wikipedia.org/wiki/Session_(computer_science) 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.&lt;ref&gt; https://github.com/servo/servo/wiki/Persistent-sessions-student-project&lt;/ref&gt;<br /> <br /> With this project we aim to create the necessary infrastructure to support this.<br /> <br /> == '''Introduction''' ==<br /> <br /> <br /> === Servo ===<br /> <br /> <br /> [https://en.wikipedia.org/wiki/Servo_(layout_engine) 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.<br /> 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.&lt;ref&gt;https://en.wikipedia.org/wiki/Servo_(layout_engine)&lt;/ref&gt;<br /> <br /> === Rust ===<br /> <br /> [http://doc.rust-lang.org/book/README 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.<br /> 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.&lt;ref&gt;https://en.wikipedia.org/wiki/Rust_(programming_language)&lt;/ref&gt;<br /> <br /> == '''Previous Work''' ==<br /> <br /> 1) Added a new command line flag &lt;code&gt; --profile-dir [path]&lt;/code&gt; that stores an optional directory path in the Opts struct in &lt;code&gt;opts.rs&lt;/code&gt;, creates the directory if it does not exist.<br /> <br /> 2) Created [http://doc.rust-lang.org/book/ffi.html Rust FFI bindings] for the &lt;code&gt;[https://github.com/jdm/tinyfiledialogs tinyfiledialogs] &lt;/code&gt;library to allow calling the C methods from Servo.<br /> <br /> 3) In &lt;code&gt;resource_thread.rs&lt;/code&gt;, defined an HTTP authorization cache storage (username, password, URL) and instantiated it like the cookie_storage member (inside an &lt;code&gt;Arc&lt;Rwlock&lt;&gt;&gt;&lt;/code&gt; value, to enable sharing it between threads).<br /> <br /> 4) In &lt;code&gt;modify_request_headers&lt;/code&gt; in &lt;code&gt;http_loader.rs&lt;/code&gt;, 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.<br /> <br /> '''A Wiki Page regarding this work can be found [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2016_OSS_M1606 here ]<br /> '''<br /> <br /> == '''Scope''' == <br /> <br /> The scope of this project is to:<br /> <br /> 1)<br /> <br /> 2)<br /> <br /> 3)<br /> <br /> 4)<br /> <br /> == '''Design Patterns''' ==<br /> 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]<br /> <br /> == '''Implementation / Design Decisions''' ==<br /> <br /> Here are some of the design decisions that we have made for implementing the steps mentioned in [http://wiki.expertiza.ncsu.edu/index.php/M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions#Scope Scope] :<br /> <br /> === Step 1 ===<br /> <br /> Objective:<br /> <br /> === Step 2 ===<br /> <br /> Objective: <br /> <br /> === Step 3 ===<br /> <br /> Objective: <br /> <br /> === Step 4 ===<br /> <br /> Objective:<br /> <br /> =='''Testing'''==<br /> <br /> ===Testing the new command line flag --profile-dir===<br /> <br /> '''[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]'''<br /> <br /> === Unit Test for set authorization header if url does not have credentials ===<br /> <br /> '''[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]'''<br /> === GUI test for the tinyfiledialogs lib===<br /> <br /> '''[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]'''<br /> <br /> == '''Conclusion''' ==<br /> <br /> =='''References'''==<br /> &lt;references/&gt;</div>

Mverma4 https://wiki.expertiza.ncsu.edu/index.php?title=M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions&diff=101799 2016-04-04T17:26:04Z

<p>Mverma4: /* Previous Work */</p> <hr /> <div>''' M1606: Implementing HTTP authorization UI and persistent sessions '''<br /> <br /> [https://en.wikipedia.org/wiki/Web_page Web pages] make use of [https://en.wikipedia.org/wiki/Session_(computer_science) 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.&lt;ref&gt; https://github.com/servo/servo/wiki/Persistent-sessions-student-project&lt;/ref&gt;<br /> <br /> With this project we aim to create the necessary infrastructure to support this.<br /> <br /> == '''Introduction''' ==<br /> <br /> <br /> === Servo ===<br /> <br /> <br /> [https://en.wikipedia.org/wiki/Servo_(layout_engine) 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.<br /> 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.&lt;ref&gt;https://en.wikipedia.org/wiki/Servo_(layout_engine)&lt;/ref&gt;<br /> <br /> === Rust ===<br /> <br /> [http://doc.rust-lang.org/book/README 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.<br /> 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.&lt;ref&gt;https://en.wikipedia.org/wiki/Rust_(programming_language)&lt;/ref&gt;<br /> <br /> == '''Previous Work''' ==<br /> <br /> 1) Added a new command line flag &lt;code&gt; --profile-dir [path]&lt;/code&gt; that stores an optional directory path in the Opts struct in &lt;code&gt;opts.rs&lt;/code&gt;, creates the directory if it does not exist.<br /> <br /> 2) Created [http://doc.rust-lang.org/book/ffi.html Rust FFI bindings] for the &lt;code&gt;[https://github.com/jdm/tinyfiledialogs tinyfiledialogs] &lt;/code&gt;library to allow calling the C methods from Servo.<br /> <br /> 3) In &lt;code&gt;resource_thread.rs&lt;/code&gt;, defined an HTTP authorization cache storage (username, password, URL) and instantiated it like the cookie_storage member (inside an &lt;code&gt;Arc&lt;Rwlock&lt;&gt;&gt;&lt;/code&gt; value, to enable sharing it between threads).<br /> <br /> 4) In &lt;code&gt;modify_request_headers&lt;/code&gt; in &lt;code&gt;http_loader.rs&lt;/code&gt;, 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.<br /> <br /> '''A Wiki Page regarding this work can be found [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2016_OSS_M1606 here ] .<br /> '''<br /> <br /> == '''Scope''' == <br /> <br /> The scope of this project is to:<br /> <br /> 1)<br /> <br /> 2)<br /> <br /> 3)<br /> <br /> 4)<br /> <br /> == '''Implementation / Design Decisions''' ==<br /> <br /> Here are some of the design decisions that we have made for implementing the steps mentioned in [http://wiki.expertiza.ncsu.edu/index.php/M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions#Scope Scope] :<br /> <br /> === Step 1 ===<br /> <br /> Objective:<br /> <br /> === Step 2 ===<br /> <br /> Objective: <br /> <br /> === Step 3 ===<br /> <br /> Objective: <br /> <br /> === Step 4 ===<br /> <br /> Objective:<br /> <br /> =='''Testing the new command line flag --profile-dir'''==<br /> <br /> git clone https://github.com/servo/servo.git<br /> <br /> cd servo<br /> <br /> ./mach build --dev<br /> <br /> ./mach run tests/html/about-mozilla.html --profile-dir [directory name]<br /> <br /> //A new folder should be created if it does not exist with the directory name<br /> <br /> == '''Unit Test for set authorization header if url does not have credentials''' ==<br /> 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 <br /> <br /> It can be run with the other unit tests with the command <br /> <br /> ./mach test-unit -p net<br /> <br /> The unit test can be found in /servo/tests/unit/net/http_loader.rs<br /> <br /> == '''GUI test for the tinyfiledialogs lib'''==<br /> 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.<br /> <br /> To run the example and see all of the tinyfiledialog windows do the following.<br /> <br /> Git clone https://github.com/jdm/tinyfiledialogs.git<br /> <br /> cd tinyfiledialogs/examples/tinytest<br /> <br /> cargo run<br /> <br /> This will run tinytest which is a rust program that show cases the different GUI windows that the new rust tinyfiledialogs library has.<br /> <br /> == '''Design Patterns''' ==<br /> 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]<br /> <br /> == '''Conclusion''' ==<br /> <br /> =='''References'''==<br /> &lt;references/&gt;</div>

Mverma4 https://wiki.expertiza.ncsu.edu/index.php?title=M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions&diff=101797 2016-04-04T17:25:41Z

<p>Mverma4: /* Previous Work */</p> <hr /> <div>''' M1606: Implementing HTTP authorization UI and persistent sessions '''<br /> <br /> [https://en.wikipedia.org/wiki/Web_page Web pages] make use of [https://en.wikipedia.org/wiki/Session_(computer_science) 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.&lt;ref&gt; https://github.com/servo/servo/wiki/Persistent-sessions-student-project&lt;/ref&gt;<br /> <br /> With this project we aim to create the necessary infrastructure to support this.<br /> <br /> == '''Introduction''' ==<br /> <br /> <br /> === Servo ===<br /> <br /> <br /> [https://en.wikipedia.org/wiki/Servo_(layout_engine) 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.<br /> 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.&lt;ref&gt;https://en.wikipedia.org/wiki/Servo_(layout_engine)&lt;/ref&gt;<br /> <br /> === Rust ===<br /> <br /> [http://doc.rust-lang.org/book/README 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.<br /> 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.&lt;ref&gt;https://en.wikipedia.org/wiki/Rust_(programming_language)&lt;/ref&gt;<br /> <br /> == '''Previous Work''' ==<br /> <br /> 1) Added a new command line flag &lt;code&gt; --profile-dir [path]&lt;/code&gt; that stores an optional directory path in the Opts struct in &lt;code&gt;opts.rs&lt;/code&gt;, creates the directory if it does not exist.<br /> <br /> 2) Created [http://doc.rust-lang.org/book/ffi.html Rust FFI bindings] for the &lt;code&gt;[https://github.com/jdm/tinyfiledialogs tinyfiledialogs] &lt;/code&gt;library to allow calling the C methods from Servo.<br /> <br /> 3) In &lt;code&gt;resource_thread.rs&lt;/code&gt;, defined an HTTP authorization cache storage (username, password, URL) and instantiated it like the cookie_storage member (inside an &lt;code&gt;Arc&lt;Rwlock&lt;&gt;&gt;&lt;/code&gt; value, to enable sharing it between threads).<br /> <br /> 4) In &lt;code&gt;modify_request_headers&lt;/code&gt; in &lt;code&gt;http_loader.rs&lt;/code&gt;, 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.<br /> <br /> A Wiki Page regarding this work can be found [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2016_OSS_M1606 here ] .<br /> <br /> == '''Scope''' == <br /> <br /> The scope of this project is to:<br /> <br /> 1)<br /> <br /> 2)<br /> <br /> 3)<br /> <br /> 4)<br /> <br /> == '''Implementation / Design Decisions''' ==<br /> <br /> Here are some of the design decisions that we have made for implementing the steps mentioned in [http://wiki.expertiza.ncsu.edu/index.php/M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions#Scope Scope] :<br /> <br /> === Step 1 ===<br /> <br /> Objective:<br /> <br /> === Step 2 ===<br /> <br /> Objective: <br /> <br /> === Step 3 ===<br /> <br /> Objective: <br /> <br /> === Step 4 ===<br /> <br /> Objective:<br /> <br /> =='''Testing the new command line flag --profile-dir'''==<br /> <br /> git clone https://github.com/servo/servo.git<br /> <br /> cd servo<br /> <br /> ./mach build --dev<br /> <br /> ./mach run tests/html/about-mozilla.html --profile-dir [directory name]<br /> <br /> //A new folder should be created if it does not exist with the directory name<br /> <br /> == '''Unit Test for set authorization header if url does not have credentials''' ==<br /> 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 <br /> <br /> It can be run with the other unit tests with the command <br /> <br /> ./mach test-unit -p net<br /> <br /> The unit test can be found in /servo/tests/unit/net/http_loader.rs<br /> <br /> == '''GUI test for the tinyfiledialogs lib'''==<br /> 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.<br /> <br /> To run the example and see all of the tinyfiledialog windows do the following.<br /> <br /> Git clone https://github.com/jdm/tinyfiledialogs.git<br /> <br /> cd tinyfiledialogs/examples/tinytest<br /> <br /> cargo run<br /> <br /> This will run tinytest which is a rust program that show cases the different GUI windows that the new rust tinyfiledialogs library has.<br /> <br /> == '''Design Patterns''' ==<br /> 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]<br /> <br /> == '''Conclusion''' ==<br /> <br /> =='''References'''==<br /> &lt;references/&gt;</div>

Mverma4 https://wiki.expertiza.ncsu.edu/index.php?title=M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions&diff=101796 2016-04-04T17:25:24Z

<p>Mverma4: /* Previous Work */</p> <hr /> <div>''' M1606: Implementing HTTP authorization UI and persistent sessions '''<br /> <br /> [https://en.wikipedia.org/wiki/Web_page Web pages] make use of [https://en.wikipedia.org/wiki/Session_(computer_science) 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.&lt;ref&gt; https://github.com/servo/servo/wiki/Persistent-sessions-student-project&lt;/ref&gt;<br /> <br /> With this project we aim to create the necessary infrastructure to support this.<br /> <br /> == '''Introduction''' ==<br /> <br /> <br /> === Servo ===<br /> <br /> <br /> [https://en.wikipedia.org/wiki/Servo_(layout_engine) 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.<br /> 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.&lt;ref&gt;https://en.wikipedia.org/wiki/Servo_(layout_engine)&lt;/ref&gt;<br /> <br /> === Rust ===<br /> <br /> [http://doc.rust-lang.org/book/README 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.<br /> 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.&lt;ref&gt;https://en.wikipedia.org/wiki/Rust_(programming_language)&lt;/ref&gt;<br /> <br /> == '''Previous Work''' ==<br /> <br /> 1) Added a new command line flag &lt;code&gt; --profile-dir [path]&lt;/code&gt; that stores an optional directory path in the Opts struct in &lt;code&gt;opts.rs&lt;/code&gt;, creates the directory if it does not exist.<br /> <br /> 2) Created [http://doc.rust-lang.org/book/ffi.html Rust FFI bindings] for the &lt;code&gt;[https://github.com/jdm/tinyfiledialogs tinyfiledialogs] &lt;/code&gt;library to allow calling the C methods from Servo.<br /> <br /> 3) In &lt;code&gt;resource_thread.rs&lt;/code&gt;, defined an HTTP authorization cache storage (username, password, URL) and instantiated it like the cookie_storage member (inside an &lt;code&gt;Arc&lt;Rwlock&lt;&gt;&gt;&lt;/code&gt; value, to enable sharing it between threads).<br /> <br /> 4) In &lt;code&gt;modify_request_headers&lt;/code&gt; in &lt;code&gt;http_loader.rs&lt;/code&gt;, 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.<br /> <br /> A Wiki Page regarding this work can be found [ http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2016_OSS_M1606 here ] .<br /> <br /> == '''Scope''' == <br /> <br /> The scope of this project is to:<br /> <br /> 1)<br /> <br /> 2)<br /> <br /> 3)<br /> <br /> 4)<br /> <br /> == '''Implementation / Design Decisions''' ==<br /> <br /> Here are some of the design decisions that we have made for implementing the steps mentioned in [http://wiki.expertiza.ncsu.edu/index.php/M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions#Scope Scope] :<br /> <br /> === Step 1 ===<br /> <br /> Objective:<br /> <br /> === Step 2 ===<br /> <br /> Objective: <br /> <br /> === Step 3 ===<br /> <br /> Objective: <br /> <br /> === Step 4 ===<br /> <br /> Objective:<br /> <br /> =='''Testing the new command line flag --profile-dir'''==<br /> <br /> git clone https://github.com/servo/servo.git<br /> <br /> cd servo<br /> <br /> ./mach build --dev<br /> <br /> ./mach run tests/html/about-mozilla.html --profile-dir [directory name]<br /> <br /> //A new folder should be created if it does not exist with the directory name<br /> <br /> == '''Unit Test for set authorization header if url does not have credentials''' ==<br /> 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 <br /> <br /> It can be run with the other unit tests with the command <br /> <br /> ./mach test-unit -p net<br /> <br /> The unit test can be found in /servo/tests/unit/net/http_loader.rs<br /> <br /> == '''GUI test for the tinyfiledialogs lib'''==<br /> 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.<br /> <br /> To run the example and see all of the tinyfiledialog windows do the following.<br /> <br /> Git clone https://github.com/jdm/tinyfiledialogs.git<br /> <br /> cd tinyfiledialogs/examples/tinytest<br /> <br /> cargo run<br /> <br /> This will run tinytest which is a rust program that show cases the different GUI windows that the new rust tinyfiledialogs library has.<br /> <br /> == '''Design Patterns''' ==<br /> 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]<br /> <br /> == '''Conclusion''' ==<br /> <br /> =='''References'''==<br /> &lt;references/&gt;</div>

Mverma4 https://wiki.expertiza.ncsu.edu/index.php?title=M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions&diff=101795 2016-04-04T17:22:25Z

<p>Mverma4: /* Implementation / Design Decisions */</p> <hr /> <div>''' M1606: Implementing HTTP authorization UI and persistent sessions '''<br /> <br /> [https://en.wikipedia.org/wiki/Web_page Web pages] make use of [https://en.wikipedia.org/wiki/Session_(computer_science) 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.&lt;ref&gt; https://github.com/servo/servo/wiki/Persistent-sessions-student-project&lt;/ref&gt;<br /> <br /> With this project we aim to create the necessary infrastructure to support this.<br /> <br /> == '''Introduction''' ==<br /> <br /> <br /> === Servo ===<br /> <br /> <br /> [https://en.wikipedia.org/wiki/Servo_(layout_engine) 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.<br /> 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.&lt;ref&gt;https://en.wikipedia.org/wiki/Servo_(layout_engine)&lt;/ref&gt;<br /> <br /> === Rust ===<br /> <br /> [http://doc.rust-lang.org/book/README 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.<br /> 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.&lt;ref&gt;https://en.wikipedia.org/wiki/Rust_(programming_language)&lt;/ref&gt;<br /> <br /> == '''Previous Work''' ==<br /> <br /> 1) Added a new command line flag &lt;code&gt; --profile-dir [path]&lt;/code&gt; that stores an optional directory path in the Opts struct in &lt;code&gt;opts.rs&lt;/code&gt;, creates the directory if it does not exist.<br /> <br /> 2) Created [http://doc.rust-lang.org/book/ffi.html Rust FFI bindings] for the &lt;code&gt;[https://github.com/jdm/tinyfiledialogs tinyfiledialogs] &lt;/code&gt;library to allow calling the C methods from Servo.<br /> <br /> 3) In &lt;code&gt;resource_thread.rs&lt;/code&gt;, defined an HTTP authorization cache storage (username, password, URL) and instantiated it like the cookie_storage member (inside an &lt;code&gt;Arc&lt;Rwlock&lt;&gt;&gt;&lt;/code&gt; value, to enable sharing it between threads).<br /> <br /> 4) In &lt;code&gt;modify_request_headers&lt;/code&gt; in &lt;code&gt;http_loader.rs&lt;/code&gt;, 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.<br /> <br /> == '''Scope''' == <br /> <br /> The scope of this project is to:<br /> <br /> 1)<br /> <br /> 2)<br /> <br /> 3)<br /> <br /> 4)<br /> <br /> == '''Implementation / Design Decisions''' ==<br /> <br /> Here are some of the design decisions that we have made for implementing the steps mentioned in [http://wiki.expertiza.ncsu.edu/index.php/M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions#Scope Scope] :<br /> <br /> === Step 1 ===<br /> <br /> Objective:<br /> <br /> === Step 2 ===<br /> <br /> Objective: <br /> <br /> === Step 3 ===<br /> <br /> Objective: <br /> <br /> === Step 4 ===<br /> <br /> Objective:<br /> <br /> =='''Testing the new command line flag --profile-dir'''==<br /> <br /> git clone https://github.com/servo/servo.git<br /> <br /> cd servo<br /> <br /> ./mach build --dev<br /> <br /> ./mach run tests/html/about-mozilla.html --profile-dir [directory name]<br /> <br /> //A new folder should be created if it does not exist with the directory name<br /> <br /> == '''Unit Test for set authorization header if url does not have credentials''' ==<br /> 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 <br /> <br /> It can be run with the other unit tests with the command <br /> <br /> ./mach test-unit -p net<br /> <br /> The unit test can be found in /servo/tests/unit/net/http_loader.rs<br /> <br /> == '''GUI test for the tinyfiledialogs lib'''==<br /> 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.<br /> <br /> To run the example and see all of the tinyfiledialog windows do the following.<br /> <br /> Git clone https://github.com/jdm/tinyfiledialogs.git<br /> <br /> cd tinyfiledialogs/examples/tinytest<br /> <br /> cargo run<br /> <br /> This will run tinytest which is a rust program that show cases the different GUI windows that the new rust tinyfiledialogs library has.<br /> <br /> == '''Design Patterns''' ==<br /> 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]<br /> <br /> == '''Conclusion''' ==<br /> <br /> =='''References'''==<br /> &lt;references/&gt;</div>

Mverma4 https://wiki.expertiza.ncsu.edu/index.php?title=M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions&diff=101794 2016-04-04T17:21:59Z

<p>Mverma4: </p> <hr /> <div>''' M1606: Implementing HTTP authorization UI and persistent sessions '''<br /> <br /> [https://en.wikipedia.org/wiki/Web_page Web pages] make use of [https://en.wikipedia.org/wiki/Session_(computer_science) 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.&lt;ref&gt; https://github.com/servo/servo/wiki/Persistent-sessions-student-project&lt;/ref&gt;<br /> <br /> With this project we aim to create the necessary infrastructure to support this.<br /> <br /> == '''Introduction''' ==<br /> <br /> <br /> === Servo ===<br /> <br /> <br /> [https://en.wikipedia.org/wiki/Servo_(layout_engine) 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.<br /> 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.&lt;ref&gt;https://en.wikipedia.org/wiki/Servo_(layout_engine)&lt;/ref&gt;<br /> <br /> === Rust ===<br /> <br /> [http://doc.rust-lang.org/book/README 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.<br /> 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.&lt;ref&gt;https://en.wikipedia.org/wiki/Rust_(programming_language)&lt;/ref&gt;<br /> <br /> == '''Previous Work''' ==<br /> <br /> 1) Added a new command line flag &lt;code&gt; --profile-dir [path]&lt;/code&gt; that stores an optional directory path in the Opts struct in &lt;code&gt;opts.rs&lt;/code&gt;, creates the directory if it does not exist.<br /> <br /> 2) Created [http://doc.rust-lang.org/book/ffi.html Rust FFI bindings] for the &lt;code&gt;[https://github.com/jdm/tinyfiledialogs tinyfiledialogs] &lt;/code&gt;library to allow calling the C methods from Servo.<br /> <br /> 3) In &lt;code&gt;resource_thread.rs&lt;/code&gt;, defined an HTTP authorization cache storage (username, password, URL) and instantiated it like the cookie_storage member (inside an &lt;code&gt;Arc&lt;Rwlock&lt;&gt;&gt;&lt;/code&gt; value, to enable sharing it between threads).<br /> <br /> 4) In &lt;code&gt;modify_request_headers&lt;/code&gt; in &lt;code&gt;http_loader.rs&lt;/code&gt;, 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.<br /> <br /> == '''Scope''' == <br /> <br /> The scope of this project is to:<br /> <br /> 1)<br /> <br /> 2)<br /> <br /> 3)<br /> <br /> 4)<br /> <br /> == '''Implementation / Design Decisions''' ==<br /> <br /> Here are some of the design decisions that we have made for implementing the steps mentioned in [https://en.wikipedia.org/wiki/Web_page Scope] :<br /> <br /> === Step 1 ===<br /> <br /> Objective:<br /> <br /> === Step 2 ===<br /> <br /> Objective: <br /> <br /> === Step 3 ===<br /> <br /> Objective: <br /> <br /> === Step 4 ===<br /> <br /> Objective:<br /> <br /> <br /> =='''Testing the new command line flag --profile-dir'''==<br /> <br /> git clone https://github.com/servo/servo.git<br /> <br /> cd servo<br /> <br /> ./mach build --dev<br /> <br /> ./mach run tests/html/about-mozilla.html --profile-dir [directory name]<br /> <br /> //A new folder should be created if it does not exist with the directory name<br /> <br /> == '''Unit Test for set authorization header if url does not have credentials''' ==<br /> 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 <br /> <br /> It can be run with the other unit tests with the command <br /> <br /> ./mach test-unit -p net<br /> <br /> The unit test can be found in /servo/tests/unit/net/http_loader.rs<br /> <br /> == '''GUI test for the tinyfiledialogs lib'''==<br /> 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.<br /> <br /> To run the example and see all of the tinyfiledialog windows do the following.<br /> <br /> Git clone https://github.com/jdm/tinyfiledialogs.git<br /> <br /> cd tinyfiledialogs/examples/tinytest<br /> <br /> cargo run<br /> <br /> This will run tinytest which is a rust program that show cases the different GUI windows that the new rust tinyfiledialogs library has.<br /> <br /> == '''Design Patterns''' ==<br /> 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]<br /> <br /> == '''Conclusion''' ==<br /> <br /> =='''References'''==<br /> &lt;references/&gt;</div>

Mverma4 https://wiki.expertiza.ncsu.edu/index.php?title=M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions&diff=101793 2016-04-04T17:13:57Z

<p>Mverma4: </p> <hr /> <div>''' M1606: Implementing HTTP authorization UI and persistent sessions '''<br /> <br /> [https://en.wikipedia.org/wiki/Web_page Web pages] make use of [https://en.wikipedia.org/wiki/Session_(computer_science) 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.&lt;ref&gt; https://github.com/servo/servo/wiki/Persistent-sessions-student-project&lt;/ref&gt;<br /> <br /> With this project we aim to create the necessary infrastructure to support this.<br /> <br /> == '''Introduction''' ==<br /> <br /> <br /> === Servo ===<br /> <br /> <br /> [https://en.wikipedia.org/wiki/Servo_(layout_engine) 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.<br /> 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.&lt;ref&gt;https://en.wikipedia.org/wiki/Servo_(layout_engine)&lt;/ref&gt;<br /> <br /> === Rust ===<br /> <br /> [http://doc.rust-lang.org/book/README 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.<br /> 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.&lt;ref&gt;https://en.wikipedia.org/wiki/Rust_(programming_language)&lt;/ref&gt;<br /> <br /> == '''Previous Work''' ==<br /> <br /> 1) Added a new command line flag &lt;code&gt; --profile-dir [path]&lt;/code&gt; that stores an optional directory path in the Opts struct in &lt;code&gt;opts.rs&lt;/code&gt;, creates the directory if it does not exist.<br /> <br /> 2) Created [http://doc.rust-lang.org/book/ffi.html Rust FFI bindings] for the &lt;code&gt;[https://github.com/jdm/tinyfiledialogs tinyfiledialogs] &lt;/code&gt;library to allow calling the C methods from Servo.<br /> <br /> 3) In &lt;code&gt;resource_thread.rs&lt;/code&gt;, defined an HTTP authorization cache storage (username, password, URL) and instantiated it like the cookie_storage member (inside an &lt;code&gt;Arc&lt;Rwlock&lt;&gt;&gt;&lt;/code&gt; value, to enable sharing it between threads).<br /> <br /> 4) In &lt;code&gt;modify_request_headers&lt;/code&gt; in &lt;code&gt;http_loader.rs&lt;/code&gt;, 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.<br /> <br /> == '''Scope''' == <br /> <br /> The scope of this project is to:<br /> <br /> <br /> <br /> == '''Implementation''' ==<br /> <br /> =='''Testing the new command line flag --profile-dir'''==<br /> <br /> git clone https://github.com/servo/servo.git<br /> <br /> cd servo<br /> <br /> ./mach build --dev<br /> <br /> ./mach run tests/html/about-mozilla.html --profile-dir [directory name]<br /> <br /> //A new folder should be created if it does not exist with the directory name<br /> <br /> == '''Unit Test for set authorization header if url does not have credentials''' ==<br /> 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 <br /> <br /> It can be run with the other unit tests with the command <br /> <br /> ./mach test-unit -p net<br /> <br /> The unit test can be found in /servo/tests/unit/net/http_loader.rs<br /> <br /> == '''GUI test for the tinyfiledialogs lib'''==<br /> 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.<br /> <br /> To run the example and see all of the tinyfiledialog windows do the following.<br /> <br /> Git clone https://github.com/jdm/tinyfiledialogs.git<br /> <br /> cd tinyfiledialogs/examples/tinytest<br /> <br /> cargo run<br /> <br /> This will run tinytest which is a rust program that show cases the different GUI windows that the new rust tinyfiledialogs library has.<br /> <br /> == '''Design Patterns''' ==<br /> 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]<br /> <br /> == '''Conclusion''' ==<br /> <br /> =='''References'''==<br /> &lt;references/&gt;</div>

Mverma4 https://wiki.expertiza.ncsu.edu/index.php?title=M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions&diff=101792 2016-04-04T17:06:00Z

<p>Mverma4: </p> <hr /> <div>''' M1606: Implementing HTTP authorization UI and persistent sessions '''<br /> <br /> [https://en.wikipedia.org/wiki/Web_page Web pages] make use of [https://en.wikipedia.org/wiki/Session_(computer_science) 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.&lt;ref&gt; https://github.com/servo/servo/wiki/Persistent-sessions-student-project&lt;/ref&gt;<br /> <br /> With this project we aim to create the necessary infrastructure to support this.<br /> <br /> == '''Introduction''' ==<br /> <br /> <br /> === Servo ===<br /> <br /> <br /> [https://en.wikipedia.org/wiki/Servo_(layout_engine) 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.<br /> 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.&lt;ref&gt;https://en.wikipedia.org/wiki/Servo_(layout_engine)&lt;/ref&gt;<br /> <br /> === Rust ===<br /> <br /> [http://doc.rust-lang.org/book/README 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.<br /> 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.&lt;ref&gt;https://en.wikipedia.org/wiki/Rust_(programming_language)&lt;/ref&gt;<br /> <br /> == '''Previous Work''' ==<br /> <br /> 1) Added a new command line flag &lt;code&gt; --profile-dir [path]&lt;/code&gt; that stores an optional directory path in the Opts struct in &lt;code&gt;opts.rs&lt;/code&gt;, creating the directory if it does not exist.<br /> <br /> 3) Create [http://doc.rust-lang.org/book/ffi.html Rust FFI bindings] for the &lt;code&gt;[https://github.com/jdm/tinyfiledialogs tinyfiledialogs] &lt;/code&gt;library to allow calling the C methods from Servo.<br /> <br /> 4) In &lt;code&gt;resource_thread.rs&lt;/code&gt;, define an HTTP authorization cache storage (username, password, URL) and instantiate it like the cookie_storage member (inside an &lt;code&gt;Arc&lt;Rwlock&lt;&gt;&gt;&lt;/code&gt; value, to enable sharing it between threads).<br /> <br /> 5) In &lt;code&gt;modify_request_headers&lt;/code&gt; in &lt;code&gt;http_loader.rs&lt;/code&gt;, implement the remaining pieces of step 12 of the [https://fetch.spec.whatwg.org/#http-network-or-cache-fetch appropriate specification ] using this new authorization cache.<br /> <br /> == '''Scope''' == <br /> <br /> The scope of this project is to:<br /> <br /> <br /> <br /> == '''Implementation''' ==<br /> <br /> =='''Testing the new command line flag --profile-dir'''==<br /> <br /> git clone https://github.com/servo/servo.git<br /> <br /> cd servo<br /> <br /> ./mach build --dev<br /> <br /> ./mach run tests/html/about-mozilla.html --profile-dir [directory name]<br /> <br /> //A new folder should be created if it does not exist with the directory name<br /> <br /> == '''Unit Test for set authorization header if url does not have credentials''' ==<br /> 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 <br /> <br /> It can be run with the other unit tests with the command <br /> <br /> ./mach test-unit -p net<br /> <br /> The unit test can be found in /servo/tests/unit/net/http_loader.rs<br /> <br /> == '''GUI test for the tinyfiledialogs lib'''==<br /> 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.<br /> <br /> To run the example and see all of the tinyfiledialog windows do the following.<br /> <br /> Git clone https://github.com/jdm/tinyfiledialogs.git<br /> <br /> cd tinyfiledialogs/examples/tinytest<br /> <br /> cargo run<br /> <br /> This will run tinytest which is a rust program that show cases the different GUI windows that the new rust tinyfiledialogs library has.<br /> <br /> == '''Design patterns''' ==<br /> 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]<br /> <br /> == '''Conclusion''' ==<br /> <br /> =='''References'''==<br /> &lt;references/&gt;</div>

Mverma4 https://wiki.expertiza.ncsu.edu/index.php?title=User_talk:Mverma4&diff=101791 2016-04-04T17:00:53Z

<p>Mverma4: moved User talk:Mverma4 to Talk:M1606: Implementing HTTP authorization UI and persistent sessions</p> <hr /> <div>#REDIRECT [[Talk:M1606: Implementing HTTP authorization UI and persistent sessions]]</div>

Mverma4 https://wiki.expertiza.ncsu.edu/index.php?title=Talk:M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions&diff=101790 2016-04-04T17:00:53Z

<p>Mverma4: moved User talk:Mverma4 to Talk:M1606: Implementing HTTP authorization UI and persistent sessions</p> <hr /> <div>#REDIRECT [[CSC/ECE 517 Fall 2016/ OSS M1606]]</div>

Mverma4 https://wiki.expertiza.ncsu.edu/index.php?title=User:Mverma4&diff=101789 2016-04-04T17:00:52Z

<p>Mverma4: moved User:Mverma4 to M1606: Implementing HTTP authorization UI and persistent sessions</p> <hr /> <div>#REDIRECT [[M1606: Implementing HTTP authorization UI and persistent sessions]]</div>

Mverma4 https://wiki.expertiza.ncsu.edu/index.php?title=M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions&diff=101788 2016-04-04T17:00:52Z

<p>Mverma4: moved User:Mverma4 to M1606: Implementing HTTP authorization UI and persistent sessions</p> <hr /> <div>''' M1606: Implementing HTTP authorization UI and persistent sessions '''<br /> <br /> [https://en.wikipedia.org/wiki/Web_page Web pages] make use of [https://en.wikipedia.org/wiki/Session_(computer_science) 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.&lt;ref&gt; https://github.com/servo/servo/wiki/Persistent-sessions-student-project&lt;/ref&gt;<br /> <br /> With this project we aim to create the necessary infrastructure to support this.<br /> <br /> == '''Introduction''' ==<br /> <br /> <br /> === Servo ===<br /> <br /> <br /> [https://en.wikipedia.org/wiki/Servo_(layout_engine) 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.<br /> 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.&lt;ref&gt;https://en.wikipedia.org/wiki/Servo_(layout_engine)&lt;/ref&gt;<br /> <br /> === Rust ===<br /> <br /> [http://doc.rust-lang.org/book/README 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.<br /> 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.&lt;ref&gt;https://en.wikipedia.org/wiki/Rust_(programming_language)&lt;/ref&gt;<br /> <br /> == '''Scope''' == <br /> <br /> The scope of the project is limited to the steps mentioned below:<br /> <br /> 1) Compile Servo and ensure that it runs on &lt;code&gt;tests/html/about-mozilla.html&lt;/code&gt;.<br /> <br /> 2) Add a new command line flag &lt;code&gt; --profile-dir [path]&lt;/code&gt; that stores an optional directory path in the Opts struct in &lt;code&gt;opts.rs&lt;/code&gt;, creating the directory if it does not exist.<br /> <br /> 3) Create [http://doc.rust-lang.org/book/ffi.html Rust FFI bindings] for the &lt;code&gt;[https://github.com/jdm/tinyfiledialogs tinyfiledialogs] &lt;/code&gt;library to allow calling the C methods from Servo.<br /> <br /> 4) In &lt;code&gt;resource_thread.rs&lt;/code&gt;, define an HTTP authorization cache storage (username, password, URL) and instantiate it like the cookie_storage member (inside an &lt;code&gt;Arc&lt;Rwlock&lt;&gt;&gt;&lt;/code&gt; value, to enable sharing it between threads).<br /> <br /> 5) In &lt;code&gt;modify_request_headers&lt;/code&gt; in &lt;code&gt;http_loader.rs&lt;/code&gt;, implement the remaining pieces of step 12 of the [https://fetch.spec.whatwg.org/#http-network-or-cache-fetch appropriate specification ] using this new authorization cache.<br /> <br /> == '''Implementation''' ==<br /> <br /> This is a quick summary of the changes. Not all code is shown. To see a more detailed view of the code changes look at the pull requests or commits in the repo.<br /> <br /> === Step 1: === <br /> <br /> The project requirement initially stated that we build and Compile servo. Servo is built with Cargo, the Rust package manager. Mozilla's Mach tools are used to orchestrate the build and other tasks.<br /> <br /> === Step 2: === <br /> <br /> The project required us to add a new command line flag that stored an optional directory path. The job of this flag was to create a directory in the absence of it.<br /> <br /> [[File:Step2Wiki2spring16.jpg]]<br /> <br /> === Step 3: ===<br /> <br /> To create the Rust FFI bindings for the &lt;code&gt;tinyfiledialogs&lt;/code&gt; library so as to allow the C methods to be called from Servo.<br /> <br /> An example program that uses the tinyfiledialogs bindings has been placed in /examples/tinytest<br /> <br /> [[File:Step3-1Wiki2spring16.jpg]]<br /> <br /> [[File:Step3-2Wiki2spring16.jpg]]<br /> <br /> === Step 4: ===<br /> <br /> In the file &lt;code&gt;resource_thread.rs&lt;/code&gt;, we were required to define an HTTP authorization cache storage (username, password, URL) and instantiate it like the cookie_storage member. <br /> <br /> [[File:Step4Wiki2spring16.jpg]]<br /> <br /> === Step 5: ===<br /> <br /> In the&lt;code&gt; modify_request_headers&lt;/code&gt; in &lt;code&gt;http_loader.rs&lt;/code&gt;, we were required to implement a portion of the appropriate specification using this new authorization cache.<br /> <br /> [[File:Step5Wiki2spring16.jpg]]<br /> <br /> == '''Pull Requests''' ==<br /> All pull requests that fully implement the initial steps have been accepted by a servo maintainer and successfully merged to the servo master branch<br /> <br /> These are the pull requests that complete the initial steps of the project:<br /> <br /> 1) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/servo/servo/pull/10087 Added a new command line flag --profile-dir ]&lt;/span&gt;<br /> <br /> 2) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/jdm/tinyfiledialogs/pull/1 Added Rust FFI bindings to lib.rs ]&lt;/span&gt;<br /> <br /> 3) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/servo/servo/pull/10111 Added authorization cache to resources &amp; set authorization header from it if url does not have credentials ]&lt;/span&gt;<br /> <br /> =='''Testing the new command line flag --profile-dir'''==<br /> <br /> git clone https://github.com/servo/servo.git<br /> <br /> cd servo<br /> <br /> ./mach build --dev<br /> <br /> ./mach run tests/html/about-mozilla.html --profile-dir [directory name]<br /> <br /> //A new folder should be created if it does not exist with the directory name<br /> <br /> == '''Unit Test for set authorization header if url does not have credentials''' ==<br /> 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 <br /> <br /> It can be run with the other unit tests with the command <br /> <br /> ./mach test-unit -p net<br /> <br /> The unit test can be found in /servo/tests/unit/net/http_loader.rs<br /> <br /> == '''GUI test for the tinyfiledialogs lib'''==<br /> 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.<br /> <br /> To run the example and see all of the tinyfiledialog windows do the following.<br /> <br /> Git clone https://github.com/jdm/tinyfiledialogs.git<br /> <br /> cd tinyfiledialogs/examples/tinytest<br /> <br /> cargo run<br /> <br /> This will run tinytest which is a rust program that show cases the different GUI windows that the new rust tinyfiledialogs library has.<br /> <br /> == '''Design patterns''' ==<br /> 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]<br /> <br /> == '''Conclusion''' ==<br /> <br /> The definition of the HTTP authorization cache and the implementation of the appropriate specification in the &lt;code&gt;http_loader.rs&lt;/code&gt;, ensures the authorization UI will appear when a 401 HTTP response is received. <br /> <br /> The Rust FFI Bindings for the &lt;code&gt;tinyfiledialogs&lt;/code&gt; library will ultimately help with the dialogue box that will pop up in event of a 401 HTTP response. <br /> <br /> The&lt;code&gt; –profile-dir [path]&lt;/code&gt; command line flag will store an optional directory path, creating the directory in case it doesn’t exist.<br /> <br /> =='''References'''==<br /> &lt;references/&gt;</div>

Mverma4 https://wiki.expertiza.ncsu.edu/index.php?title=M1606:_Implementing_HTTP_authorization_UI_and_persistent_sessions&diff=101787 2016-04-04T17:00:11Z

<p>Mverma4: M1606: Implementing HTTP authorization UI and persistent sessions</p> <hr /> <div>''' M1606: Implementing HTTP authorization UI and persistent sessions '''<br /> <br /> [https://en.wikipedia.org/wiki/Web_page Web pages] make use of [https://en.wikipedia.org/wiki/Session_(computer_science) 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.&lt;ref&gt; https://github.com/servo/servo/wiki/Persistent-sessions-student-project&lt;/ref&gt;<br /> <br /> With this project we aim to create the necessary infrastructure to support this.<br /> <br /> == '''Introduction''' ==<br /> <br /> <br /> === Servo ===<br /> <br /> <br /> [https://en.wikipedia.org/wiki/Servo_(layout_engine) 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.<br /> 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.&lt;ref&gt;https://en.wikipedia.org/wiki/Servo_(layout_engine)&lt;/ref&gt;<br /> <br /> === Rust ===<br /> <br /> [http://doc.rust-lang.org/book/README 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.<br /> 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.&lt;ref&gt;https://en.wikipedia.org/wiki/Rust_(programming_language)&lt;/ref&gt;<br /> <br /> == '''Scope''' == <br /> <br /> The scope of the project is limited to the steps mentioned below:<br /> <br /> 1) Compile Servo and ensure that it runs on &lt;code&gt;tests/html/about-mozilla.html&lt;/code&gt;.<br /> <br /> 2) Add a new command line flag &lt;code&gt; --profile-dir [path]&lt;/code&gt; that stores an optional directory path in the Opts struct in &lt;code&gt;opts.rs&lt;/code&gt;, creating the directory if it does not exist.<br /> <br /> 3) Create [http://doc.rust-lang.org/book/ffi.html Rust FFI bindings] for the &lt;code&gt;[https://github.com/jdm/tinyfiledialogs tinyfiledialogs] &lt;/code&gt;library to allow calling the C methods from Servo.<br /> <br /> 4) In &lt;code&gt;resource_thread.rs&lt;/code&gt;, define an HTTP authorization cache storage (username, password, URL) and instantiate it like the cookie_storage member (inside an &lt;code&gt;Arc&lt;Rwlock&lt;&gt;&gt;&lt;/code&gt; value, to enable sharing it between threads).<br /> <br /> 5) In &lt;code&gt;modify_request_headers&lt;/code&gt; in &lt;code&gt;http_loader.rs&lt;/code&gt;, implement the remaining pieces of step 12 of the [https://fetch.spec.whatwg.org/#http-network-or-cache-fetch appropriate specification ] using this new authorization cache.<br /> <br /> == '''Implementation''' ==<br /> <br /> This is a quick summary of the changes. Not all code is shown. To see a more detailed view of the code changes look at the pull requests or commits in the repo.<br /> <br /> === Step 1: === <br /> <br /> The project requirement initially stated that we build and Compile servo. Servo is built with Cargo, the Rust package manager. Mozilla's Mach tools are used to orchestrate the build and other tasks.<br /> <br /> === Step 2: === <br /> <br /> The project required us to add a new command line flag that stored an optional directory path. The job of this flag was to create a directory in the absence of it.<br /> <br /> [[File:Step2Wiki2spring16.jpg]]<br /> <br /> === Step 3: ===<br /> <br /> To create the Rust FFI bindings for the &lt;code&gt;tinyfiledialogs&lt;/code&gt; library so as to allow the C methods to be called from Servo.<br /> <br /> An example program that uses the tinyfiledialogs bindings has been placed in /examples/tinytest<br /> <br /> [[File:Step3-1Wiki2spring16.jpg]]<br /> <br /> [[File:Step3-2Wiki2spring16.jpg]]<br /> <br /> === Step 4: ===<br /> <br /> In the file &lt;code&gt;resource_thread.rs&lt;/code&gt;, we were required to define an HTTP authorization cache storage (username, password, URL) and instantiate it like the cookie_storage member. <br /> <br /> [[File:Step4Wiki2spring16.jpg]]<br /> <br /> === Step 5: ===<br /> <br /> In the&lt;code&gt; modify_request_headers&lt;/code&gt; in &lt;code&gt;http_loader.rs&lt;/code&gt;, we were required to implement a portion of the appropriate specification using this new authorization cache.<br /> <br /> [[File:Step5Wiki2spring16.jpg]]<br /> <br /> == '''Pull Requests''' ==<br /> All pull requests that fully implement the initial steps have been accepted by a servo maintainer and successfully merged to the servo master branch<br /> <br /> These are the pull requests that complete the initial steps of the project:<br /> <br /> 1) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/servo/servo/pull/10087 Added a new command line flag --profile-dir ]&lt;/span&gt;<br /> <br /> 2) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/jdm/tinyfiledialogs/pull/1 Added Rust FFI bindings to lib.rs ]&lt;/span&gt;<br /> <br /> 3) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/servo/servo/pull/10111 Added authorization cache to resources &amp; set authorization header from it if url does not have credentials ]&lt;/span&gt;<br /> <br /> =='''Testing the new command line flag --profile-dir'''==<br /> <br /> git clone https://github.com/servo/servo.git<br /> <br /> cd servo<br /> <br /> ./mach build --dev<br /> <br /> ./mach run tests/html/about-mozilla.html --profile-dir [directory name]<br /> <br /> //A new folder should be created if it does not exist with the directory name<br /> <br /> == '''Unit Test for set authorization header if url does not have credentials''' ==<br /> 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 <br /> <br /> It can be run with the other unit tests with the command <br /> <br /> ./mach test-unit -p net<br /> <br /> The unit test can be found in /servo/tests/unit/net/http_loader.rs<br /> <br /> == '''GUI test for the tinyfiledialogs lib'''==<br /> 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.<br /> <br /> To run the example and see all of the tinyfiledialog windows do the following.<br /> <br /> Git clone https://github.com/jdm/tinyfiledialogs.git<br /> <br /> cd tinyfiledialogs/examples/tinytest<br /> <br /> cargo run<br /> <br /> This will run tinytest which is a rust program that show cases the different GUI windows that the new rust tinyfiledialogs library has.<br /> <br /> == '''Design patterns''' ==<br /> 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]<br /> <br /> == '''Conclusion''' ==<br /> <br /> The definition of the HTTP authorization cache and the implementation of the appropriate specification in the &lt;code&gt;http_loader.rs&lt;/code&gt;, ensures the authorization UI will appear when a 401 HTTP response is received. <br /> <br /> The Rust FFI Bindings for the &lt;code&gt;tinyfiledialogs&lt;/code&gt; library will ultimately help with the dialogue box that will pop up in event of a 401 HTTP response. <br /> <br /> The&lt;code&gt; –profile-dir [path]&lt;/code&gt; command line flag will store an optional directory path, creating the directory in case it doesn’t exist.<br /> <br /> =='''References'''==<br /> &lt;references/&gt;</div>

Mverma4 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016&diff=101501 2016-03-30T16:27:18Z

<p>Mverma4: /* Writing Assignment 2 */</p> <hr /> <div>==Writing Assignment 1==<br /> *[[CSC/ECE 517 Spring 2016/Active Job]]<br /> <br /> <br /> ==Calibration Assignment Submissions==<br /> *[[Calibration Assignment Submission (OmniAuth)]]<br /> *[[Calibration Assignment Submission (Patch_verb)]]<br /> <br /> ==Writing Assignment 2==<br /> *[[CSC/ECE 517 Spring 2016/Mozilla Implement HTML5 form validation]]<br /> <br /> *[[CSC/ECE 517 Spring 2016/Functional Tests for Questionnaire Controller]]<br /> <br /> *[[CSC/ECE 517 Spring 2016 / Expertiza Self-Review Feature]]<br /> <br /> *[[CSC/ECE 517 Spring 2016/Refactor different question types from quiz feature]]<br /> <br /> *[[CSC/ECE 517 Spring 2016/Implement private browsing]]<br /> <br /> *[[CSC/ECE 517 Spring 2016/Write automated tests for WebDriver]]<br /> <br /> *[[CSC/ECE 517 Spring 2016/Refactor sign_up_sheet_controller.rb and sign_up_topic.rb]]<br /> <br /> *[[CSC/ECE 517 Spring 2016/Implement Common Parts of the CSSOM API]]<br /> <br /> *[[CSC/ECE 517 Spring 2016/Functional tests for assignment creation function]]<br /> <br /> *[[CSC/ECE 517 Spring 2016/E1604. Functional tests for Calibration function]]<br /> <br /> *[[CSC/ECE 517 Spring 2016/Refactor and write unit tests for question type.rb]]<br /> <br /> *[[CSC/ECE 517 Spring 2016/Refactor response controller]]<br /> <br /> *[[CSC/ECE_517_Spring_2016_OSS_M1606]]</div>

Mverma4 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016_OSS_M1606&diff=101099 2016-03-22T23:40:49Z

<p>Mverma4: </p> <hr /> <div>''' M1606: Implementing HTTP authorization UI and persistent sessions '''<br /> <br /> [https://en.wikipedia.org/wiki/Web_page Web pages] make use of [https://en.wikipedia.org/wiki/Session_(computer_science) 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.&lt;ref&gt; https://github.com/servo/servo/wiki/Persistent-sessions-student-project&lt;/ref&gt;<br /> <br /> With this project we aim to create the necessary infrastructure to support this.<br /> <br /> == '''Introduction''' ==<br /> <br /> <br /> === Servo ===<br /> <br /> <br /> [https://en.wikipedia.org/wiki/Servo_(layout_engine) 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.<br /> 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.&lt;ref&gt;https://en.wikipedia.org/wiki/Servo_(layout_engine)&lt;/ref&gt;<br /> <br /> === Rust ===<br /> <br /> [http://doc.rust-lang.org/book/README 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.<br /> 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.&lt;ref&gt;https://en.wikipedia.org/wiki/Rust_(programming_language)&lt;/ref&gt;<br /> <br /> == '''Scope''' == <br /> <br /> The scope of the project is limited to the steps mentioned below:<br /> <br /> 1) Compile Servo and ensure that it runs on &lt;code&gt;tests/html/about-mozilla.html&lt;/code&gt;.<br /> <br /> 2) Add a new command line flag &lt;code&gt; --profile-dir [path]&lt;/code&gt; that stores an optional directory path in the Opts struct in &lt;code&gt;opts.rs&lt;/code&gt;, creating the directory if it does not exist.<br /> <br /> 3) Create [http://doc.rust-lang.org/book/ffi.html Rust FFI bindings] for the &lt;code&gt;[https://github.com/jdm/tinyfiledialogs tinyfiledialogs] &lt;/code&gt;library to allow calling the C methods from Servo.<br /> <br /> 4) In &lt;code&gt;resource_thread.rs&lt;/code&gt;, define an HTTP authorization cache storage (username, password, URL) and instantiate it like the cookie_storage member (inside an &lt;code&gt;Arc&lt;Rwlock&lt;&gt;&gt;&lt;/code&gt; value, to enable sharing it between threads).<br /> <br /> 5) In &lt;code&gt;modify_request_headers&lt;/code&gt; in &lt;code&gt;http_loader.rs&lt;/code&gt;, implement the remaining pieces of step 12 of the [https://fetch.spec.whatwg.org/#http-network-or-cache-fetch appropriate specification ] using this new authorization cache.<br /> <br /> == '''Implementation''' ==<br /> <br /> === Step 1: === <br /> <br /> The project requirement initially stated that we build and Compile servo. Servo is built with Cargo, the Rust package manager. Mozilla's Mach tools are used to orchestrate the build and other tasks.<br /> <br /> === Step 2: === <br /> <br /> The project required us to add a new command line flag that stored an optional directory path. The job of this flag was to create a directory in the absence of it.<br /> <br /> [[File:Step2Wiki2spring16.jpg]]<br /> <br /> === Step 3: ===<br /> <br /> To create the Rust FFI bindings for the &lt;code&gt;tinyfiledialogs&lt;/code&gt; library so as to allow the C methods to be called from Servo.<br /> <br /> [[File:Step3-1Wiki2spring16.jpg]]<br /> <br /> [[File:Step3-2Wiki2spring16.jpg]]<br /> <br /> === Step 4: ===<br /> <br /> In the file &lt;code&gt;resource_thread.rs&lt;/code&gt;, we were required to define an HTTP authorization cache storage (username, password, URL) and instantiate it like the cookie_storage member. <br /> <br /> [[File:Step4Wiki2spring16.jpg]]<br /> <br /> === Step 5: ===<br /> <br /> In the&lt;code&gt; modify_request_headers&lt;/code&gt; in &lt;code&gt;http_loader.rs&lt;/code&gt;, we were required to implement a portion of the appropriate specification using this new authorization cache.<br /> <br /> [[File:Step5Wiki2spring16.jpg]]<br /> <br /> == '''Pull Request''' ==<br /> <br /> These are the pull requests for the modifications we’ve made:<br /> <br /> 1) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/servo/servo/pull/10087 Added a new command line flag --profile-dir ]&lt;/span&gt;<br /> <br /> 2) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/jdm/tinyfiledialogs/pull/1 Added Rust FFI bindings to lib.rs ]&lt;/span&gt;<br /> <br /> 3) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/servo/servo/pull/10111 Added authorization cache to resources &amp; set authorization header from it if url does not have credentials ]&lt;/span&gt;<br /> <br /> == '''Conclusion''' ==<br /> <br /> The definition of the HTTP authorization cache and the implementation of the appropriate specification in the &lt;code&gt;http_loader.rs&lt;/code&gt;, ensures the authorization UI will appear when a 401 HTTP response is received. <br /> <br /> The Rust FFI Bindings for the &lt;code&gt;tinyfiledialogs&lt;/code&gt; library will ultimately help with the dialogue box that will pop up in event of a 401 HTTP response. <br /> <br /> The&lt;code&gt; –profile-dir [path]&lt;/code&gt; command line flag will store an optional directory path, creating the directory in case it doesn’t exist.<br /> <br /> =='''References'''==<br /> &lt;references/&gt;</div>

Mverma4 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016_OSS_M1606&diff=101096 2016-03-22T23:38:09Z

<p>Mverma4: </p> <hr /> <div>''' M1606: Implementing HTTP authorization UI and persistent sessions '''<br /> <br /> [ https://en.wikipedia.org/wiki/Web_page Web pages ] make use of [ https://en.wikipedia.org/wiki/Session_(computer_science) 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.&lt;ref&gt; https://github.com/servo/servo/wiki/Persistent-sessions-student-project&lt;/ref&gt;<br /> <br /> With this project we aim to create the necessary infrastructure to support this.<br /> <br /> == '''Introduction''' ==<br /> <br /> <br /> === Servo ===<br /> <br /> <br /> [https://en.wikipedia.org/wiki/Servo_(layout_engine) 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.<br /> 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.&lt;ref&gt;https://en.wikipedia.org/wiki/Servo_(layout_engine)&lt;/ref&gt;<br /> <br /> === Rust ===<br /> <br /> [http://doc.rust-lang.org/book/README 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.<br /> 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.&lt;ref&gt;https://en.wikipedia.org/wiki/Rust_(programming_language)&lt;/ref&gt;<br /> <br /> == '''Scope''' == <br /> <br /> The scope of the project is limited to the steps mentioned below:<br /> <br /> 1) Compile Servo and ensure that it runs on &lt;code&gt;tests/html/about-mozilla.html&lt;/code&gt;.<br /> <br /> 2) Add a new command line flag &lt;code&gt; --profile-dir [path]&lt;/code&gt; that stores an optional directory path in the Opts struct in &lt;code&gt;opts.rs&lt;/code&gt;, creating the directory if it does not exist.<br /> <br /> 3) Create [http://doc.rust-lang.org/book/ffi.html Rust FFI bindings] for the &lt;code&gt;[https://github.com/jdm/tinyfiledialogs tinyfiledialogs] &lt;/code&gt;library to allow calling the C methods from Servo.<br /> <br /> 4) In &lt;code&gt;resource_thread.rs&lt;/code&gt;, define an HTTP authorization cache storage (username, password, URL) and instantiate it like the cookie_storage member (inside an &lt;code&gt;Arc&lt;Rwlock&lt;&gt;&gt;&lt;/code&gt; value, to enable sharing it between threads).<br /> <br /> 5) In &lt;code&gt;modify_request_headers&lt;/code&gt; in &lt;code&gt;http_loader.rs&lt;/code&gt;, implement the remaining pieces of step 12 of the [https://fetch.spec.whatwg.org/#http-network-or-cache-fetch appropriate specification ] using this new authorization cache.<br /> <br /> == '''Implementation''' ==<br /> <br /> === Step 1: === <br /> <br /> The project requirement initially stated that we build and Compile servo. Servo is built with Cargo, the Rust package manager. Mozilla's Mach tools are used to orchestrate the build and other tasks.<br /> <br /> === Step 2: === <br /> <br /> The project required us to add a new command line flag that stored an optional directory path. The job of this flag was to create a directory in the absence of it.<br /> <br /> [[File:Step2Wiki2spring16.jpg]]<br /> <br /> === Step 3: ===<br /> <br /> To create the Rust FFI bindings for the &lt;code&gt;tinyfiledialogs&lt;/code&gt; library so as to allow the C methods to be called from Servo.<br /> <br /> [[File:Step3-1Wiki2spring16.jpg]]<br /> <br /> [[File:Step3-2Wiki2spring16.jpg]]<br /> <br /> === Step 4: ===<br /> <br /> In the file &lt;code&gt;resource_thread.rs&lt;/code&gt;, we were required to define an HTTP authorization cache storage (username, password, URL) and instantiate it like the cookie_storage member. <br /> <br /> [[File:Step4Wiki2spring16.jpg]]<br /> <br /> === Step 5: ===<br /> <br /> In the&lt;code&gt; modify_request_headers&lt;/code&gt; in &lt;code&gt;http_loader.rs&lt;/code&gt;, we were required to implement a portion of the appropriate specification using this new authorization cache.<br /> <br /> [[File:Step5Wiki2spring16.jpg]]<br /> <br /> == '''Pull Request''' ==<br /> <br /> These are the pull requests for the modifications we’ve made:<br /> <br /> 1) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/servo/servo/pull/10087 Added a new command line flag --profile-dir ]&lt;/span&gt;<br /> <br /> 2) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/jdm/tinyfiledialogs/pull/1 Added Rust FFI bindings to lib.rs ]&lt;/span&gt;<br /> <br /> 3) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/servo/servo/pull/10111 Added authorization cache to resources &amp; set authorization header from it if url does not have credentials ]&lt;/span&gt;<br /> <br /> == '''Conclusion''' ==<br /> <br /> The definition of the HTTP authorization cache and the implementation of the appropriate specification in the &lt;code&gt;http_loader.rs&lt;/code&gt;, ensures the authorization UI will appear when a 401 HTTP response is received. <br /> <br /> The Rust FFI Bindings for the &lt;code&gt;tinyfiledialogs&lt;/code&gt; library will ultimately help with the dialogue box that will pop up in event of a 401 HTTP response. <br /> <br /> The&lt;code&gt; –profile-dir [path]&lt;/code&gt; command line flag will store an optional directory path, creating the directory in case it doesn’t exist.<br /> <br /> =='''References'''==<br /> &lt;references/&gt;</div>

Mverma4 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016_OSS_M1606&diff=101092 2016-03-22T23:27:17Z

<p>Mverma4: </p> <hr /> <div>''' M1606: Implementing HTTP authorization UI and persistent sessions '''<br /> <br /> 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.&lt;ref&gt; https://github.com/servo/servo/wiki/Persistent-sessions-student-project&lt;/ref&gt;<br /> <br /> With this project we aim to create the necessary infrastructure to support this.<br /> <br /> == '''Introduction''' ==<br /> <br /> <br /> === Servo ===<br /> <br /> <br /> [https://en.wikipedia.org/wiki/Servo_(layout_engine) 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.<br /> 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.&lt;ref&gt;https://en.wikipedia.org/wiki/Servo_(layout_engine)&lt;/ref&gt;<br /> <br /> === Rust ===<br /> <br /> [http://doc.rust-lang.org/book/README 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.<br /> 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.&lt;ref&gt;https://en.wikipedia.org/wiki/Rust_(programming_language)&lt;/ref&gt;<br /> <br /> == '''Scope''' == <br /> <br /> The scope of the project is limited to the steps mentioned below:<br /> <br /> 1) Compile Servo and ensure that it runs on tests/html/about-mozilla.html.<br /> <br /> 2) Add a new command line flag &lt;code&gt; --profile-dir [path]&lt;/code&gt; that stores an optional directory path in the Opts struct in &lt;code&gt;opts.rs&lt;/code&gt;, creating the directory if it does not exist.<br /> <br /> 3) Create Rust FFI bindings for the &lt;code&gt;tinyfiledialogs &lt;/code&gt;library to allow calling the C methods from Servo.<br /> <br /> 4) In &lt;code&gt;resource_thread.rs&lt;/code&gt;, define an HTTP authorization cache storage (username, password, URL) and instantiate it like the cookie_storage member (inside an &lt;code&gt;Arc&lt;Rwlock&lt;&gt;&gt;&lt;/code&gt; value, to enable sharing it between threads).<br /> <br /> 5) In &lt;code&gt;modify_request_headers&lt;/code&gt; in &lt;code&gt;http_loader.rs&lt;/code&gt;, implement the remaining pieces of step 12 of the appropriate specification using this new authorization cache.<br /> <br /> == '''Implementation''' ==<br /> <br /> === Step 1: === <br /> <br /> The project requirement initially stated that we build and Compile servo. Servo is built with Cargo, the Rust package manager. Mozilla's Mach tools are used to orchestrate the build and other tasks.<br /> <br /> === Step 2: === <br /> <br /> The project required us to add a new command line flag that stored an optional directory path. The job of this flag was to create a directory in the absence of it.<br /> <br /> [[File:Step2Wiki2spring16.jpg]]<br /> <br /> === Step 3: ===<br /> <br /> To create the Rust FFI bindings for the &lt;code&gt;tinyfiledialogs&lt;/code&gt; library so as to allow the C methods to be called from Servo.<br /> <br /> [[File:Step3-1Wiki2spring16.jpg]]<br /> <br /> [[File:Step3-2Wiki2spring16.jpg]]<br /> <br /> === Step 4: ===<br /> <br /> In the file &lt;code&gt;resource_thread.rs&lt;/code&gt;, we were required to define an HTTP authorization cache storage (username, password, URL) and instantiate it like the cookie_storage member. <br /> <br /> [[File:Step4Wiki2spring16.jpg]]<br /> <br /> === Step 5: ===<br /> <br /> In the&lt;code&gt; modify_request_headers&lt;/code&gt; in &lt;code&gt;http_loader.rs&lt;/code&gt;, we were required to implement a portion of the appropriate specification using this new authorization cache.<br /> <br /> [[File:Step5Wiki2spring16.jpg]]<br /> <br /> == '''Pull Request''' ==<br /> <br /> These are the pull requests for the modifications we’ve made:<br /> <br /> 1) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/servo/servo/pull/10087 Added a new command line flag --profile-dir ]&lt;/span&gt;<br /> <br /> 2) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/jdm/tinyfiledialogs/pull/1 Added Rust FFI bindings to lib.rs ]&lt;/span&gt;<br /> <br /> 3) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/servo/servo/pull/10111 Added authorization cache to resources &amp; set authorization header from it if url does not have credentials ]&lt;/span&gt;<br /> <br /> == '''Conclusion''' ==<br /> <br /> The definition of the HTTP authorization cache and the implementation of the appropriate specification in the &lt;code&gt;http_loader.rs&lt;/code&gt;, ensures the authorization UI will appear when a 401 HTTP response is received. <br /> <br /> The Rust FFI Bindings for the &lt;code&gt;tinyfiledialogs&lt;/code&gt; library will ultimately help with the dialogue box that will pop up in event of a 401 HTTP response. <br /> <br /> The&lt;code&gt; –profile-dir [path]&lt;/code&gt; command line flag will store an optional directory path, creating the directory in case it doesn’t exist.<br /> <br /> =='''References'''==<br /> 5. http://rustbyexample.com/&lt;br&gt;<br /> &lt;references/&gt;</div>

Mverma4 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016_OSS_M1606&diff=101079 2016-03-22T23:14:32Z

<p>Mverma4: </p> <hr /> <div>''' M1606: Implementing HTTP authorization UI and persistent sessions '''<br /> <br /> 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. <br /> <br /> With this project we aim to create the necessary infrastructure to support this.<br /> <br /> == '''Introduction''' ==<br /> <br /> <br /> === Servo ===<br /> <br /> <br /> [https://en.wikipedia.org/wiki/Servo_(layout_engine) 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.<br /> 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.<br /> <br /> === Rust ===<br /> <br /> [http://doc.rust-lang.org/book/README 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.<br /> 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.<br /> <br /> == '''Scope''' ==<br /> <br /> The scope of the project is limited to the steps mentioned below:<br /> <br /> 1) Compile Servo and ensure that it runs on tests/html/about-mozilla.html.<br /> <br /> 2) Add a new command line flag &lt;code&gt; --profile-dir [path]&lt;/code&gt; that stores an optional directory path in the Opts struct in &lt;code&gt;opts.rs&lt;/code&gt;, creating the directory if it does not exist.<br /> <br /> 3) Create Rust FFI bindings for the &lt;code&gt;tinyfiledialogs &lt;/code&gt;library to allow calling the C methods from Servo.<br /> <br /> 4) In &lt;code&gt;resource_thread.rs&lt;/code&gt;, define an HTTP authorization cache storage (username, password, URL) and instantiate it like the cookie_storage member (inside an &lt;code&gt;Arc&lt;Rwlock&lt;&gt;&gt;&lt;/code&gt; value, to enable sharing it between threads).<br /> <br /> 5) In &lt;code&gt;modify_request_headers&lt;/code&gt; in &lt;code&gt;http_loader.rs&lt;/code&gt;, implement the remaining pieces of step 12 of the appropriate specification using this new authorization cache.<br /> <br /> == '''Implementation''' ==<br /> <br /> === Step 1: === <br /> <br /> The project requirement initially stated that we build and Compile servo. Servo is built with Cargo, the Rust package manager. Mozilla's Mach tools are used to orchestrate the build and other tasks.<br /> <br /> === Step 2: === <br /> <br /> The project required us to add a new command line flag that stored an optional directory path. The job of this flag was to create a directory in the absence of it.<br /> <br /> [[File:Step2Wiki2spring16.jpg]]<br /> <br /> === Step 3: ===<br /> <br /> To create the Rust FFI bindings for the &lt;code&gt;tinyfiledialogs&lt;/code&gt; library so as to allow the C methods to be called from Servo.<br /> <br /> [[File:Step3-1Wiki2spring16.jpg]]<br /> <br /> [[File:Step3-2Wiki2spring16.jpg]]<br /> <br /> === Step 4: ===<br /> <br /> In the file &lt;code&gt;resource_thread.rs&lt;/code&gt;, we were required to define an HTTP authorization cache storage (username, password, URL) and instantiate it like the cookie_storage member. <br /> <br /> [[File:Step4Wiki2spring16.jpg]]<br /> <br /> === Step 5: ===<br /> <br /> In the&lt;code&gt; modify_request_headers&lt;/code&gt; in &lt;code&gt;http_loader.rs&lt;/code&gt;, we were required to implement a portion of the appropriate specification using this new authorization cache.<br /> <br /> [[File:Step5Wiki2spring16.jpg]]<br /> <br /> == '''Pull Request''' ==<br /> <br /> These are the pull requests for the modifications we’ve made:<br /> <br /> 1) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/servo/servo/pull/10087 Added a new command line flag --profile-dir ]&lt;/span&gt;<br /> <br /> 2) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/jdm/tinyfiledialogs/pull/1 Added Rust FFI bindings to lib.rs ]&lt;/span&gt;<br /> <br /> 3) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/servo/servo/pull/10111 Added authorization cache to resources &amp; set authorization header from it if url does not have credentials ]&lt;/span&gt;<br /> <br /> == '''Conclusion''' ==<br /> <br /> The definition of the HTTP authorization cache and the implementation of the appropriate specification in the &lt;code&gt;http_loader.rs&lt;/code&gt;, ensures the authorization UI will appear when a 401 HTTP response is received. <br /> <br /> The Rust FFI Bindings for the &lt;code&gt;tinyfiledialogs&lt;/code&gt; library will ultimately help with the dialogue box that will pop up in event of a 401 HTTP response. <br /> <br /> The&lt;code&gt; –profile-dir [path]&lt;/code&gt; command line flag will store an optional directory path, creating the directory in case it doesn’t exist.<br /> <br /> =='''References'''==<br /> 1. https://doc.rust-lang.org/stable/book/&lt;br&gt;<br /> 2. https://en.wikipedia.org/wiki/Rust_(programming_language)&lt;br&gt;<br /> 3. https://en.wikipedia.org/wiki/Servo_(layout_engine)&lt;br&gt;<br /> 4. https://github.com/servo/servo/wiki/Persistent-sessions-student-project&lt;br&gt;<br /> 5. http://rustbyexample.com/&lt;br&gt;</div>

Mverma4 https://wiki.expertiza.ncsu.edu/index.php?title=File:Step5Wiki2spring16.jpg&diff=101075 2016-03-22T23:10:48Z

<p>Mverma4: </p> <hr /> <div></div>

Mverma4 https://wiki.expertiza.ncsu.edu/index.php?title=File:Step4Wiki2spring16.jpg&diff=101074 2016-03-22T23:10:29Z

<p>Mverma4: </p> <hr /> <div></div>

Mverma4 https://wiki.expertiza.ncsu.edu/index.php?title=File:Step3-2Wiki2spring16.jpg&diff=101073 2016-03-22T23:10:08Z

<p>Mverma4: </p> <hr /> <div></div>

Mverma4 https://wiki.expertiza.ncsu.edu/index.php?title=File:Step3-1Wiki2spring16.jpg&diff=101072 2016-03-22T23:09:09Z

<p>Mverma4: </p> <hr /> <div></div>

Mverma4 https://wiki.expertiza.ncsu.edu/index.php?title=File:Step2Wiki2spring16.jpg&diff=101071 2016-03-22T23:08:42Z

<p>Mverma4: </p> <hr /> <div></div>

Mverma4 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016_OSS_M1606&diff=101065 2016-03-22T23:01:38Z

<p>Mverma4: </p> <hr /> <div>''' M1606: Implementing HTTP authorization UI and persistent sessions '''<br /> <br /> 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. <br /> <br /> With this project we aim to create the necessary infrastructure to support this.<br /> <br /> == '''Introduction''' ==<br /> <br /> <br /> === Servo ===<br /> <br /> <br /> [https://en.wikipedia.org/wiki/Servo_(layout_engine) 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.<br /> 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.<br /> <br /> === Rust ===<br /> <br /> [http://doc.rust-lang.org/book/README 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.<br /> 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.<br /> <br /> == '''Scope''' ==<br /> <br /> The scope of the project is limited to the steps mentioned below:<br /> <br /> 1) Compile Servo and ensure that it runs on tests/html/about-mozilla.html.<br /> <br /> 2) Add a new command line flag &lt;code&gt; --profile-dir [path]&lt;/code&gt; that stores an optional directory path in the Opts struct in &lt;code&gt;opts.rs&lt;/code&gt;, creating the directory if it does not exist.<br /> <br /> 3) Create Rust FFI bindings for the &lt;code&gt;tinyfiledialogs &lt;/code&gt;library to allow calling the C methods from Servo.<br /> <br /> 4) In &lt;code&gt;resource_thread.rs&lt;/code&gt;, define an HTTP authorization cache storage (username, password, URL) and instantiate it like the cookie_storage member (inside an &lt;code&gt;Arc&lt;Rwlock&lt;&gt;&gt;&lt;/code&gt; value, to enable sharing it between threads).<br /> <br /> 5) In &lt;code&gt;modify_request_headers&lt;/code&gt; in &lt;code&gt;http_loader.rs&lt;/code&gt;, implement the remaining pieces of step 12 of the appropriate specification using this new authorization cache.<br /> <br /> == '''Implementation''' ==<br /> <br /> === Step 1: === <br /> <br /> The project requirement initially stated that we build and Compile servo. Servo is built with Cargo, the Rust package manager. Mozilla's Mach tools are used to orchestrate the build and other tasks.<br /> <br /> === Step 2: === <br /> <br /> The project required us to add a new command line flag that stored an optional directory path. The job of this flag was to create a directory in the absence of it.<br /> <br /> === Step 3: ===<br /> <br /> To create the Rust FFI bindings for the &lt;code&gt;tinyfiledialogs&lt;/code&gt; library so as to allow the C methods to be called from Servo.<br /> <br /> === Step 4: ===<br /> <br /> In the file &lt;code&gt;resource_thread.rs&lt;/code&gt;, we were required to define an HTTP authorization cache storage (username, password, URL) and instantiate it like the cookie_storage member. <br /> <br /> === Step 5: ===<br /> <br /> In the&lt;code&gt; modify_request_headers&lt;/code&gt; in &lt;code&gt;http_loader.rs&lt;/code&gt;, we were required to implement a portion of the appropriate specification using this new authorization cache.<br /> <br /> == '''Pull Request''' ==<br /> <br /> These are the pull requests for the modifications we’ve made:<br /> <br /> 1) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/servo/servo/pull/10087 Added a new command line flag --profile-dir ]&lt;/span&gt;<br /> <br /> 2) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/jdm/tinyfiledialogs/pull/1 Added Rust FFI bindings to lib.rs ]&lt;/span&gt;<br /> <br /> 3) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/servo/servo/pull/10111 Added authorization cache to resources &amp; set authorization header from it if url does not have credentials ]&lt;/span&gt;<br /> <br /> == '''Conclusion''' ==<br /> <br /> The definition of the HTTP authorization cache and the implementation of the appropriate specification in the &lt;code&gt;http_loader.rs&lt;/code&gt;, ensures the authorization UI will appear when a 401 HTTP response is received. <br /> <br /> The Rust FFI Bindings for the &lt;code&gt;tinyfiledialogs&lt;/code&gt; library will ultimately help with the dialogue box that will pop up in event of a 401 HTTP response. <br /> <br /> The&lt;code&gt; –profile-dir [path]&lt;/code&gt; command line flag will store an optional directory path, creating the directory in case it doesn’t exist.<br /> <br /> =='''References'''==<br /> 1. https://doc.rust-lang.org/stable/book/&lt;br&gt;<br /> 2. https://en.wikipedia.org/wiki/Rust_(programming_language)&lt;br&gt;<br /> 3. https://en.wikipedia.org/wiki/Servo_(layout_engine)&lt;br&gt;<br /> 4. https://github.com/servo/servo/wiki/Persistent-sessions-student-project&lt;br&gt;<br /> 5. http://rustbyexample.com/&lt;br&gt;</div>

Mverma4 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016_OSS_M1606&diff=101062 2016-03-22T22:57:34Z

<p>Mverma4: </p> <hr /> <div>''' M1606: Implementing HTTP authorization UI and persistent sessions '''<br /> <br /> 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.<br /> <br /> The above 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. With this project we aim to create the necessary infrastructure to support this.<br /> <br /> == '''Introduction''' ==<br /> <br /> <br /> === Servo ===<br /> <br /> <br /> 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.<br /> 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.<br /> <br /> === Rust ===<br /> <br /> 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.<br /> 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.<br /> <br /> == '''Scope''' ==<br /> <br /> The scope of the project is limited to the steps mentioned below:<br /> <br /> 1) Compile Servo and ensure that it runs on tests/html/about-mozilla.html.<br /> <br /> 2) Add a new command line flag &lt;code&gt; --profile-dir [path]&lt;/code&gt; that stores an optional directory path in the Opts struct in &lt;code&gt;opts.rs&lt;/code&gt;, creating the directory if it does not exist.<br /> <br /> 3) Create Rust FFI bindings for the &lt;code&gt;tinyfiledialogs &lt;/code&gt;library to allow calling the C methods from Servo.<br /> <br /> 4) In &lt;code&gt;resource_thread.rs&lt;/code&gt;, define an HTTP authorization cache storage (username, password, URL) and instantiate it like the cookie_storage member (inside an &lt;code&gt;Arc&lt;Rwlock&lt;&gt;&gt;&lt;/code&gt; value, to enable sharing it between threads).<br /> <br /> 5) In &lt;code&gt;modify_request_headers&lt;/code&gt; in &lt;code&gt;http_loader.rs&lt;/code&gt;, implement the remaining pieces of step 12 of the appropriate specification using this new authorization cache.<br /> <br /> == '''Implementation''' ==<br /> <br /> === Step 1: === <br /> <br /> The project requirement initially stated that we build and Compile servo. Servo is built with Cargo, the Rust package manager. Mozilla's Mach tools are used to orchestrate the build and other tasks.<br /> <br /> === Step 2: === <br /> <br /> The project required us to add a new command line flag that stored an optional directory path. The job of this flag was to create a directory in the absence of it.<br /> <br /> === Step 3: ===<br /> <br /> To create the Rust FFI bindings for the &lt;code&gt;tinyfiledialogs&lt;/code&gt; library so as to allow the C methods to be called from Servo.<br /> <br /> === Step 4: ===<br /> <br /> In the file &lt;code&gt;resource_thread.rs&lt;/code&gt;, we were required to define an HTTP authorization cache storage (username, password, URL) and instantiate it like the cookie_storage member. <br /> <br /> === Step 5: ===<br /> <br /> In the&lt;code&gt; modify_request_headers&lt;/code&gt; in &lt;code&gt;http_loader.rs&lt;/code&gt;, we were required to implement a portion of the appropriate specification using this new authorization cache.<br /> <br /> == '''Pull Request''' ==<br /> <br /> These are the pull requests for the modifications we’ve made:<br /> <br /> 1) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/servo/servo/pull/10087 Added a new command line flag --profile-dir ]&lt;/span&gt;<br /> <br /> 2) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/jdm/tinyfiledialogs/pull/1 Added FFI bindings to lib.rs ]&lt;/span&gt;<br /> <br /> 3) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/servo/servo/pull/10111 Added authorization cache to resources &amp; set authorization header from it if url does not have credentials ]&lt;/span&gt;<br /> <br /> == '''Conclusion''' ==<br /> <br /> The definition of the HTTP authorization cache and the implementation of the appropriate specification in the &lt;code&gt;http_loader.rs&lt;/code&gt;, ensures the authorization UI will appear when a 401 HTTP response is received. <br /> <br /> The Rust FFI Bindings for the &lt;code&gt;tinyfiledialogs&lt;/code&gt; library will ultimately help with the dialogue box that will pop up in event of a 401 HTTP response. <br /> <br /> The&lt;code&gt; –profile-dir [path]&lt;/code&gt; command line flag will store an optional directory path, creating the directory in case it doesn’t exist.<br /> <br /> =='''References'''==<br /> 1. https://doc.rust-lang.org/stable/book/&lt;br&gt;<br /> 2. https://en.wikipedia.org/wiki/Rust_(programming_language)&lt;br&gt;<br /> 3. https://en.wikipedia.org/wiki/Servo_(layout_engine)&lt;br&gt;<br /> 4. https://github.com/servo/servo/wiki/Persistent-sessions-student-project&lt;br&gt;<br /> 5. http://rustbyexample.com/&lt;br&gt;</div>

Mverma4 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016_OSS_M1606&diff=101060 2016-03-22T22:55:21Z

<p>Mverma4: </p> <hr /> <div>''' M1606: Implementing HTTP authorization UI and persistent sessions '''<br /> <br /> 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.<br /> <br /> The above 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. With this project we aim to create the necessary infrastructure to support this.<br /> <br /> == '''Introduction''' ==<br /> <br /> <br /> === Servo ===<br /> <br /> <br /> 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.<br /> 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.<br /> <br /> === Rust ===<br /> <br /> 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.<br /> 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.<br /> <br /> == '''Scope''' ==<br /> <br /> The scope of the project is limited to the steps mentioned below:<br /> <br /> 1) Compile Servo and ensure that it runs on tests/html/about-mozilla.html.<br /> <br /> 2) Add a new command line flag &lt;code&gt; --profile-dir [path]&lt;/code&gt; that stores an optional directory path in the Opts struct in &lt;code&gt;opts.rs&lt;/code&gt;, creating the directory if it does not exist.<br /> <br /> 3) Create Rust FFI bindings for the &lt;code&gt;tinyfiledialogs &lt;/code&gt;library to allow calling the C methods from Servo.<br /> <br /> 4) In &lt;code&gt;resource_thread.rs&lt;/code&gt;, define an HTTP authorization cache storage (username, password, URL) and instantiate it like the cookie_storage member (inside an &lt;code&gt;Arc&lt;Rwlock&lt;&gt;&gt;&lt;/code&gt; value, to enable sharing it between threads).<br /> <br /> 5) In &lt;code&gt;modify_request_headers&lt;/code&gt; in &lt;code&gt;http_loader.rs&lt;/code&gt;, implement the remaining pieces of step 12 of the appropriate specification using this new authorization cache.<br /> <br /> == '''Implementation''' ==<br /> <br /> === Step 1: === <br /> <br /> The project requirement initially stated that we build and Compile servo. Servo is built with Cargo, the Rust package manager. Mozilla's Mach tools are used to orchestrate the build and other tasks.<br /> <br /> === Step 2: === <br /> <br /> The project required us to add a new command line flag that stored an optional directory path. The job of this flag was to create a directory in the absence of it.<br /> <br /> === Step 3: ===<br /> <br /> To create the Rust FFI bindings for the &lt;code&gt;tinyfiledialogs&lt;/code&gt; library so as to allow the C methods to be called from Servo.<br /> <br /> === Step 4: ===<br /> <br /> In the file &lt;code&gt;resource_thread.rs&lt;/code&gt;, we were required to define an HTTP authorization cache storage (username, password, URL) and instantiate it like the cookie_storage member. <br /> <br /> === Step 5: ===<br /> <br /> In the&lt;code&gt; modify_request_headers&lt;/code&gt; in &lt;code&gt;http_loader.rs&lt;/code&gt;, we were required to implement a portion of the appropriate specification using this new authorization cache.<br /> <br /> == '''Pull Request''' ==<br /> <br /> These are the pull requests for the modifications we’ve made:<br /> <br /> 1) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/servo/servo/pull/10087 Added a new command line flag --profile-dir ]&lt;/span&gt;<br /> <br /> 2) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/jdm/tinyfiledialogs/pull/1 Added FFI bindings to lib.rs ]&lt;/span&gt;<br /> <br /> 3) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/servo/servo/pull/10111 Added authorization cache to resources &amp; set authorization header from it if url does not have credentials ]&lt;/span&gt;<br /> <br /> == '''Conclusion''' ==<br /> <br /> The definition of the HTTP authorization cache and the implementation of the appropriate specification in the &lt;code&gt;http_loader.rs&lt;/code&gt;, ensures the authorization UI will appear when a 401 HTTP response is received. <br /> <br /> The Rust FFI Bindings for the &lt;code&gt;tinyfiledialogs&lt;/code&gt; library will ultimately help with the dialogue box that will pop up in event of a 401 HTTP response. <br /> <br /> The&lt;code&gt; –profile-dir [path]&lt;/code&gt; command line flag will store an optional directory path, creating the directory in case it doesn’t exist.</div>

Mverma4 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016_OSS_M1606&diff=101059 2016-03-22T22:50:13Z

<p>Mverma4: </p> <hr /> <div>''' M1606: Implementing HTTP authorization UI and persistent sessions '''<br /> <br /> 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.<br /> <br /> The above 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. With this project we aim to create the necessary infrastructure to support this.<br /> <br /> == '''Introduction''' ==<br /> <br /> <br /> === Servo ===<br /> <br /> <br /> 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.<br /> 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.<br /> <br /> === Rust ===<br /> <br /> 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.<br /> 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.<br /> <br /> == '''Scope''' ==<br /> <br /> The scope of the project is limited to the steps mentioned below:<br /> <br /> 1) Compile Servo and ensure that it runs on tests/html/about-mozilla.html.<br /> <br /> 2) Add a new command line flag --profile-dir [path] that stores an optional directory path in the Opts struct in opts.rs, creating the directory if it does not exist.<br /> <br /> 3) Create Rust FFI bindings for the tinyfiledialogs library to allow calling the C methods from Servo.<br /> <br /> 4) In resource_thread.rs, define an HTTP authorization cache storage (username, password, URL) and instantiate it like the cookie_storage member (inside an Arc&lt;Rwlock&lt;&gt;&gt; value, to enable sharing it between threads).<br /> <br /> 5) In modify_request_headers in http_loader.rs, implement the remaining pieces of step 12 of the appropriate specification using this new authorization cache.<br /> <br /> == '''Implementation''' ==<br /> <br /> === Step 1: === <br /> <br /> The project requirement initially stated that we build and Compile servo. Servo is built with Cargo, the Rust package manager. Mozilla's Mach tools are used to orchestrate the build and other tasks.<br /> <br /> === Step 2: === <br /> <br /> The project required us to add a new command line flag that stored an optional directory path. The job of this flag was to create a directory in the absence of it.<br /> <br /> === Step 3: ===<br /> <br /> To create the Rust FFI bindings for the tinyfiledialogs library so as to allow the C methods to be called from Servo.<br /> <br /> === Step 4: ===<br /> <br /> In the file resource_thread.rs, we were required to define an HTTP authorization cache storage (username, password, URL) and instantiate it like the cookie_storage member. <br /> <br /> === Step 5: ===<br /> <br /> In the modify_request_headers in http_loader.rs, we were required to implement a portion of the appropriate specification using this new authorization cache.<br /> <br /> == '''Pull Request''' ==<br /> <br /> These are the pull requests for the modifications we’ve made:<br /> <br /> 1) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/servo/servo/pull/10087 Added a new command line flag --profile-dir ]&lt;/span&gt;<br /> <br /> 2) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/jdm/tinyfiledialogs/pull/1 Added FFI bindings to lib.rs ]&lt;/span&gt;<br /> <br /> 3) &lt;span class=&quot;plainlinks&quot;&gt;[https://github.com/servo/servo/pull/10111 Added authentication cache to resources &amp; set authentication header from it if url does not have credentials ]&lt;/span&gt;<br /> <br /> == '''Conclusion''' ==<br /> <br /> <br /> The definition of the HTTP authorization cache and the implementation of the appropriate specification in the http_loader.rs, ensures the authorization UI will appear when a 401 HTTP response is received. <br /> <br /> The Rust FFI Bindings for the tinyfiledialogs library will ultimately help with the dialogue box that will pop up in event of a 401 HTTP response. <br /> <br /> The –profile-dir [path] command line flag will store an optional directory path, creating the directory in case it doesn’t exist.</div>

Mverma4 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2016/_OSS_M1606&diff=101057 2016-03-22T22:43:29Z

<p>Mverma4: moved CSC/ECE 517 Fall 2016/ OSS M1606 to CSC/ECE 517 Spring 2016 OSS M1606</p> <hr /> <div>#REDIRECT [[CSC/ECE 517 Spring 2016 OSS M1606]]</div>

Mverma4 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016_OSS_M1606&diff=101056 2016-03-22T22:43:29Z

<p>Mverma4: moved CSC/ECE 517 Fall 2016/ OSS M1606 to CSC/ECE 517 Spring 2016 OSS M1606</p> <hr /> <div>== ''' M1606: Implementing HTTP authorization UI and persistent sessions ''' ==<br /> <br /> 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.<br /> <br /> The above 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. With this project we aim to create the necessary infrastructure to support this.<br /> <br /> == '''Introduction''' ==<br /> <br /> <br /> === Servo ===<br /> <br /> <br /> 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.<br /> 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.<br /> <br /> === Rust ===<br /> <br /> 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.<br /> 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.<br /> <br /> == '''Scope''' ==<br /> <br /> The scope of the project is limited to the steps mentioned below:<br /> <br /> 1) Compile Servo and ensure that it runs on tests/html/about-mozilla.html.<br /> <br /> 2) Add a new command line flag --profile-dir [path] that stores an optional directory path in the Opts struct in opts.rs, creating the directory if it does not exist.<br /> <br /> 3) Create Rust FFI bindings for the tinyfiledialogs library to allow calling the C methods from Servo.<br /> <br /> 4) In resource_thread.rs, define an HTTP authorization cache storage (username, password, URL) and instantiate it like the cookie_storage member (inside an Arc&lt;Rwlock&lt;&gt;&gt; value, to enable sharing it between threads).<br /> <br /> 5) In modify_request_headers in http_loader.rs, implement the remaining pieces of step 12 of the appropriate specification using this new authorization cache.<br /> <br /> == '''Implementation''' ==<br /> <br /> '''Step 1:''' <br /> <br /> The project requirement initially stated that we build and Compile servo. Servo is built with Cargo, the Rust package manager. Mozilla's Mach tools are used to orchestrate the build and other tasks.<br /> <br /> '''Step 2:''' <br /> <br /> The project required us to add a new command line flag that stored an optional directory path. The job of this flag was to create a directory in the absence of it.<br /> <br /> '''Step 3:''' <br /> <br /> To create the Rust FFI bindings for the tinyfiledialogs library so as to allow the C methods to be called from Servo.<br /> <br /> '''Step 4:''' <br /> <br /> In the file resource_thread.rs, we were required to define an HTTP authorization cache storage (username, password, URL) and instantiate it like the cookie_storage member. <br /> <br /> '''Step 5:''' <br /> <br /> In the modify_request_headers in http_loader.rs, we were required to implement a portion of the appropriate specification using this new authorization cache.<br /> <br /> == '''Pull Request''' ==<br /> <br /> These are the pull requests for the modifications we’ve made:<br /> <br /> 1) Added a new command line flag --profile-dir [path]:<br /> <br /> https://github.com/servo/servo/pull/10087<br /> <br /> 2) Added FFI bindings to lib.rs:<br /> <br /> https://github.com/jdm/tinyfiledialogs/pull/1<br /> <br /> 3) Added auth cache to resources + set auth header from it if url does not have credentials:<br /> <br /> https://github.com/servo/servo/pull/10111<br /> <br /> == '''Conclusion''' ==<br /> <br /> <br /> The definition of the HTTP authorization cache and the implementation of the appropriate specification in the http_loader.rs, ensures the authorization UI will appear when a 401 HTTP response is received. <br /> <br /> The Rust FFI Bindings for the tinyfiledialogs library will ultimately help with the dialogue box that will pop up in event of a 401 HTTP response. <br /> <br /> The –profile-dir [path] command line flag will store an optional directory path, creating the directory in case it doesn’t exist.</div>

Mverma4 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2016_OSS_M1606&diff=101054 2016-03-22T22:42:31Z

<p>Mverma4: </p> <hr /> <div>== ''' M1606: Implementing HTTP authorization UI and persistent sessions ''' ==<br /> <br /> 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.<br /> <br /> The above 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. With this project we aim to create the necessary infrastructure to support this.<br /> <br /> == '''Introduction''' ==<br /> <br /> <br /> === Servo ===<br /> <br /> <br /> 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.<br /> 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.<br /> <br /> === Rust ===<br /> <br /> 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.<br /> 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.<br /> <br /> == '''Scope''' ==<br /> <br /> The scope of the project is limited to the steps mentioned below:<br /> <br /> 1) Compile Servo and ensure that it runs on tests/html/about-mozilla.html.<br /> <br /> 2) Add a new command line flag --profile-dir [path] that stores an optional directory path in the Opts struct in opts.rs, creating the directory if it does not exist.<br /> <br /> 3) Create Rust FFI bindings for the tinyfiledialogs library to allow calling the C methods from Servo.<br /> <br /> 4) In resource_thread.rs, define an HTTP authorization cache storage (username, password, URL) and instantiate it like the cookie_storage member (inside an Arc&lt;Rwlock&lt;&gt;&gt; value, to enable sharing it between threads).<br /> <br /> 5) In modify_request_headers in http_loader.rs, implement the remaining pieces of step 12 of the appropriate specification using this new authorization cache.<br /> <br /> == '''Implementation''' ==<br /> <br /> '''Step 1:''' <br /> <br /> The project requirement initially stated that we build and Compile servo. Servo is built with Cargo, the Rust package manager. Mozilla's Mach tools are used to orchestrate the build and other tasks.<br /> <br /> '''Step 2:''' <br /> <br /> The project required us to add a new command line flag that stored an optional directory path. The job of this flag was to create a directory in the absence of it.<br /> <br /> '''Step 3:''' <br /> <br /> To create the Rust FFI bindings for the tinyfiledialogs library so as to allow the C methods to be called from Servo.<br /> <br /> '''Step 4:''' <br /> <br /> In the file resource_thread.rs, we were required to define an HTTP authorization cache storage (username, password, URL) and instantiate it like the cookie_storage member. <br /> <br /> '''Step 5:''' <br /> <br /> In the modify_request_headers in http_loader.rs, we were required to implement a portion of the appropriate specification using this new authorization cache.<br /> <br /> == '''Pull Request''' ==<br /> <br /> These are the pull requests for the modifications we’ve made:<br /> <br /> 1) Added a new command line flag --profile-dir [path]:<br /> <br /> https://github.com/servo/servo/pull/10087<br /> <br /> 2) Added FFI bindings to lib.rs:<br /> <br /> https://github.com/jdm/tinyfiledialogs/pull/1<br /> <br /> 3) Added auth cache to resources + set auth header from it if url does not have credentials:<br /> <br /> https://github.com/servo/servo/pull/10111<br /> <br /> == '''Conclusion''' ==<br /> <br /> <br /> The definition of the HTTP authorization cache and the implementation of the appropriate specification in the http_loader.rs, ensures the authorization UI will appear when a 401 HTTP response is received. <br /> <br /> The Rust FFI Bindings for the tinyfiledialogs library will ultimately help with the dialogue box that will pop up in event of a 401 HTTP response. <br /> <br /> The –profile-dir [path] command line flag will store an optional directory path, creating the directory in case it doesn’t exist.</div>

Mverma4