Jump to content

GSoC/2018/StatusReports/ThanhTrung: Difference between revisions

From KDE Community Wiki
← Older edit
 
(15 intermediate revisions by the same user not shown)
Line 16: Line 16:
This phase is to port 3 digiKam web services : Google, Facebook and Smugmug to O2. It is required to change the authentication flow but still preserve main functionalities. In general, work for this part is nearly done, except some minor existant bugs to be resolved.  
This phase is to port 3 digiKam web services : Google, Facebook and Smugmug to O2. It is required to change the authentication flow but still preserve main functionalities. In general, work for this part is nearly done, except some minor existant bugs to be resolved.  


[[File:google_photo.png]]
[[File:gphoto_permissions.png]]


According to my initial plan, I must also have finished Youtube Uploader by this time. However, since porting these web services to O2 is more important and Youtube Uploader can be finished in phase two of project, when i will be working on code factorization for other web services, the whole first part of project was then spent on porting to O2.  
 
According to my initial plan, I must also have finished Youtube Uploader by this time. However, since porting these web services to O2 is more important and Youtube Uploader can be finished in phase two of project, when I will be working on code factorization for other web services, the whole first part of project was then spent on porting to O2.  


Below is my project status.
Below is my project status.
Line 56: Line 57:
=== Coding period : Phase two  (June 15th to July 13th) ===
=== Coding period : Phase two  (June 15th to July 13th) ===


In this phase, I continue working on each web service separately to fix bugs and prepare for beta release of digiKam 6.0.0. Moreover, the main part of this phase is factoring codes for web services.  
In this phase, I continue working on each web service separately to fix bugs and prepare for beta release of digiKam 6.0.0. Moreover, the main part of this phase is factoring codes for web services.
 
Indeed, once web services use OAuth2 as authentication protocol (implemented with O2 library), codes begin repeatable, especially in talker.cpp, where the authentication flow has been implemented so far. Moreover, future vision for web services' authentication is using QtNetworkAuth as a pure Qt solution, which enhances the portability of digiKam and facilitates development and maintainability. Therefore, code factoring is an essential step in digiKam todo list.


Concretely, factoring is divided in two parts: authentication flow, and export tool GUI. It has to be mentioned that Gilles Caulier, one of my mentors, has prepared a common wizard for export tool. Thus, I took it as base ground to develop new export GUI.
Concretely, factoring is divided in two parts: authentication flow, and export tool GUI. It has to be mentioned that Gilles Caulier, one of my mentors, has prepared a common wizard for export tool. Thus, I took it as base ground to develop new export GUI.


===== Centralized authentication flow =====
===== Centralized authentication flow =====
My solution is to define a base class for talkers of all web services, which is currently handling all communication between digiKam and authorization server for access token exchange, API calls, as well as API response processing. Therefore, the idea is to group all common codes in a class, which also defines the standard authentication flow for each web service.  
Indeed, OAuth2 (or even OAuth 1.0) implementation for web services in digiKam is highly redundant, especially in talker.cpp, because the authentication flow, limited by OAuth2 (or OAuth 1.0) protocol, doesn't change much from one service to another. Hence, reimplementing OAuth2 every time for each web service makes codes become less clear, as well as requires much more efforts for scaling and maintaining.


That class contains virtual methods to control the flow, API calls and parsing API responses, which will be reimplemented depending on API specifications if needed.  
To resolve that problem, the idea is to define a base class for all web services, where we group all common codes, especially for authentication. Currently in digiKam, web service talker is the class handling all communication between digiKam and web service for access token exchange, API calls, as well as API responses processing. Hence, a base class (wstalker) for all talkers is appropriate to define the standard authentication flow and API exchanges between digiKam and web service.


[[File:auth_talkers_structure.png]]
Methods to control the flow, API calls and parsing API responses in wstalker are virtual and will be reimplemented in each web service talker, depending on API specifications.  


===== Common UI for export tool =====
Besides, in WSTalker there are also helper methods to store web service accounts that user logged in by digiKam. It allows user to choose any previous accounts to login immediately without passing normal authentication process (i.e. filling email and password in the login dialog).
The solution is very similar to the case of authentication flow. I decided to create a base class containing necessary signals and slots in common between all web services.


Besides, I also worked on this part at the same time with authentication flow fafctoring, so that I can have a GUI to test. Here are some screen shots of what I have integrated to the common wizard for export tool
'''NOTE:'''  WSTalker (base class for talkers) is only designed for web services that can be ported with O2 at present, as it groups signals/slots of O2 standard authentication flow. Other web services have their own ways for authentication via REST API, so they cannot be implemented as a derived class of wstalker. However, that may change in the future when QtNetworkAuth is used replaces O2 in digiKam.


[[File:new_intropage.png]]
===== Common GUI for export tool =====
I also worked on this part at the same time with factoring codes for authentication flow, so that I can have a GUI to test. Here are some screen shots of what I have integrated to the common wizard for export tool.


[[File:authWizard.png]]
[[File:intro_page.png]]


[[File:new_wizard_facebook1.png]]
[[File:auth_page.png]]
 
[[File:fb_ask_permissions.png]]


[[File:new_wizard_facebook3.png]]


=== Coding period : Phase three  (July14th to August 6th) ===
=== Coding period : Phase three  (July14th to August 6th) ===
After phase two, discussing with my mentors about the importance of code factoring for web services, we finally all agreed that code factoring is still the most important task to finish at the moment. In later releases of digiKam, we look forwards to replacing the current long list of web services to export to put all of them into a common wizard. Thus, I continue working on code factoring and developing that wizard in the third stage of GSoC 2018.
===== Centralized authentication flow (continue) =====
As the structure for web service talker has been established in phase two, task for phase three is completing that structure, as well as adapting it to the new GUI. Below is a simplified diagram of talkers' structure.
[[File:talkers_structure.png]]


After phase two, discussing with my mentors about the importance of code factoring for web services, we finally all agreed that code factoring is still the most important task to finish at the moment. In later releases of digiKam, we look forwards to replacing the current long list of web services to export to put all of them into a common wizard. Thus, I continue working on code factoring and developing that wizard in the third stage of GSoC 2018.
In spite of having WSTalker as base class for talker, it is necessary to have class WSAuthentication, wrapping around instance of WSTalker. WSAuthentication contains helper methods to facilitate interaction with the GUI instead of using tons of signals/slots to connect GUI and talker. Moreover, WSAuthentication also has information about web service that user chooses to export, so it is the place where we choose which derived class of WSTalker is specified.
 
WSAuthentication also allows the structure to be more flexible. For instance, WSAuthentication currently contains a pointer to WSNewAlbumDialog, base class for dialog appearing when user clicks on '''New Album''' button. Because each web service requires different information in order to create new album, the dialog is service-dependent. Therefore, the right derived class will be created when web service chosen to use by user is known. Then, when user wants to create new album, he will have the right form to fill in.
 
===== Common GUI for export tool (continue) =====
For this task, I finished some important points:
* Adapting codes for Facebook, so that it can be used with the new GUI. 
* Porting back embedded browser to display authentication dialog with QtWebKit (which previously used QtWebEngine for embedded browser).
* Adding new features to the GUI.  
 
 
One of those new features is the album-list view, where albums on user account are displayed. This album view displays not only a list of albums, but also a hierarchical visualization of them, which means that we can have albums inside albums (as the case of google drive). Below is the screenshot of images_page, where the album view is integrated.
 
[[File:images_page.png]]
 
 
After choosing items to upload, user goes to settings page, where he can choose to modify images' properties.
 
[[File:settings_page.png]]
 
 
Then, on the final page, user can watch the upload process.
 
[[File:final_page.png]]


== Important Links ==
== Important Links ==
Line 93: Line 122:
=== Git dev branch ===
=== Git dev branch ===
[https://cgit.kde.org/digikam.git/?h=gsoc18-exporttools-o2 gsoc18-exporttools-o2]
[https://cgit.kde.org/digikam.git/?h=gsoc18-exporttools-o2 gsoc18-exporttools-o2]
=== Contribution ===
[https://github.com/KDE/digikam/commits?author=TrungDinhT Commits history on master]


== Contacts ==
== Contacts ==

Latest revision as of 08:29, 12 August 2018

digiKam: Web Services tools authentication with OAuth2

digiKam is a desktop application for photos management. digiKam provides a wide range of plugins for exporting photos to web services (e.g dropbox, flickr, facebook, etc.) alowing users to easily upload their photos to cloud storage services or share photos on social networks.

Current export tool authentication process makes it far from easy-to-use for users. In addition, authentication protocols varies much for each web service, generating many difficulties for implementation and code maintaining. Hence, this project is aimed to resolve those problems by porting authentication flow with O2 library, in order to make digiKam export tool more user-friendly and more flexible for development and maintenance.

Mentors : Maik Qualmann, Gilles Caulier

Project Goals

  • Port export plugins with O2 library.
  • Factor codes of new wizard for export plugins.
  • Accomplish new wizard with features for photo processing before uploading.

Work report

Coding period : Phase one (May 14th to June 15th)

This phase is to port 3 digiKam web services : Google, Facebook and Smugmug to O2. It is required to change the authentication flow but still preserve main functionalities. In general, work for this part is nearly done, except some minor existant bugs to be resolved.


According to my initial plan, I must also have finished Youtube Uploader by this time. However, since porting these web services to O2 is more important and Youtube Uploader can be finished in phase two of project, when I will be working on code factorization for other web services, the whole first part of project was then spent on porting to O2.

Below is my project status.

Smugmug

Resolved :

  • Authentication with OAuth2
  • All methods are ported to new APIs (v2)
  • Anonymous mode is removed
Google Drive

Resolved :

  • Authentication with OAuth2
  • Export is ported to keep compatibility with O2
Google Photo

Resolved :

  • Authentication with OAuth2
  • All methods are ported to Google Photo APIs (to replace current methods based on Picasa APIs)


Unresolved :

  • Photos import from Google Photo are not visualized in digiKam
  • Cannot export to albums not created by digiKam (lack of authorization scope from Google Photo APIs)
Facebook

Resolved :

  • Authentication with OAuth2
  • All methods are ported to new API (v3) and kept compatibility with O2


Unresolved :

  • Cannot create album by digiKam
  • App review to put digiKam public mode


Coding period : Phase two (June 15th to July 13th)

In this phase, I continue working on each web service separately to fix bugs and prepare for beta release of digiKam 6.0.0. Moreover, the main part of this phase is factoring codes for web services.

Concretely, factoring is divided in two parts: authentication flow, and export tool GUI. It has to be mentioned that Gilles Caulier, one of my mentors, has prepared a common wizard for export tool. Thus, I took it as base ground to develop new export GUI.

Centralized authentication flow

Indeed, OAuth2 (or even OAuth 1.0) implementation for web services in digiKam is highly redundant, especially in talker.cpp, because the authentication flow, limited by OAuth2 (or OAuth 1.0) protocol, doesn't change much from one service to another. Hence, reimplementing OAuth2 every time for each web service makes codes become less clear, as well as requires much more efforts for scaling and maintaining.

To resolve that problem, the idea is to define a base class for all web services, where we group all common codes, especially for authentication. Currently in digiKam, web service talker is the class handling all communication between digiKam and web service for access token exchange, API calls, as well as API responses processing. Hence, a base class (wstalker) for all talkers is appropriate to define the standard authentication flow and API exchanges between digiKam and web service.

Methods to control the flow, API calls and parsing API responses in wstalker are virtual and will be reimplemented in each web service talker, depending on API specifications.

Besides, in WSTalker there are also helper methods to store web service accounts that user logged in by digiKam. It allows user to choose any previous accounts to login immediately without passing normal authentication process (i.e. filling email and password in the login dialog).

NOTE: WSTalker (base class for talkers) is only designed for web services that can be ported with O2 at present, as it groups signals/slots of O2 standard authentication flow. Other web services have their own ways for authentication via REST API, so they cannot be implemented as a derived class of wstalker. However, that may change in the future when QtNetworkAuth is used replaces O2 in digiKam.

Common GUI for export tool

I also worked on this part at the same time with factoring codes for authentication flow, so that I can have a GUI to test. Here are some screen shots of what I have integrated to the common wizard for export tool.


Coding period : Phase three (July14th to August 6th)

After phase two, discussing with my mentors about the importance of code factoring for web services, we finally all agreed that code factoring is still the most important task to finish at the moment. In later releases of digiKam, we look forwards to replacing the current long list of web services to export to put all of them into a common wizard. Thus, I continue working on code factoring and developing that wizard in the third stage of GSoC 2018.

Centralized authentication flow (continue)

As the structure for web service talker has been established in phase two, task for phase three is completing that structure, as well as adapting it to the new GUI. Below is a simplified diagram of talkers' structure.

In spite of having WSTalker as base class for talker, it is necessary to have class WSAuthentication, wrapping around instance of WSTalker. WSAuthentication contains helper methods to facilitate interaction with the GUI instead of using tons of signals/slots to connect GUI and talker. Moreover, WSAuthentication also has information about web service that user chooses to export, so it is the place where we choose which derived class of WSTalker is specified.

WSAuthentication also allows the structure to be more flexible. For instance, WSAuthentication currently contains a pointer to WSNewAlbumDialog, base class for dialog appearing when user clicks on New Album button. Because each web service requires different information in order to create new album, the dialog is service-dependent. Therefore, the right derived class will be created when web service chosen to use by user is known. Then, when user wants to create new album, he will have the right form to fill in.

Common GUI for export tool (continue)

For this task, I finished some important points:

  • Adapting codes for Facebook, so that it can be used with the new GUI.
  • Porting back embedded browser to display authentication dialog with QtWebKit (which previously used QtWebEngine for embedded browser).
  • Adding new features to the GUI.


One of those new features is the album-list view, where albums on user account are displayed. This album view displays not only a list of albums, but also a hierarchical visualization of them, which means that we can have albums inside albums (as the case of google drive). Below is the screenshot of images_page, where the album view is integrated.


After choosing items to upload, user goes to settings page, where he can choose to modify images' properties.


Then, on the final page, user can watch the upload process.

Important Links

Proposal Link

Project Proposal

Git dev branch

gsoc18-exporttools-o2

Contribution

Commits history on master

Contacts

Email: [email protected]

Github: TrungDinhT

Retrieved from "https://community.kde.org/index.php?title=GSoC/2018/StatusReports/ThanhTrung&oldid=81117"