Experiment Log
Authentication - RBAC
Carried out by Horatiu Ilie
| Experiment | Title | Details | Results | Success and Failure | Date |
|---|---|---|---|---|---|
| EA1 | Using Azure Active Directory | - tested Active Directory from portal to see how users are managed and how permissions can be changed - created a separate directory on the subscription for testing purposes only - added new users, created permissions and removed them in order to see how the solution behaves |
Decided Azure Active Directory might be a good solution | Success | 14/11 |
| EA2 | Connecting to Azure from CLI | - connected to Azure from Microsoft Windows Command Prompt - wanted to test if you can remotely manage resources (such as Active Directory) from a remote terminal - installed Azure CLI using npm in order to connect to azure with my credentials |
Successfully connected to Azure remotely | Success | 20/11 |
| EA3 | Managing Active Directory from CLI | - remotely managed Azure Active Directory from CLI - added new users, added/changed/deleted permissions - remotely created new roles and added them on Active Directory |
Successfully did everything from CLI | Success | 23/11 |
| EA4 | Set up a new authentication realm in Keycloak | - successfully started Keycloak on local machine - successfully accessed and set up an admin account |
Successfully downloaded Keycloak and run it from the Command Prompt | Success | 01/02 |
| EA5 | Set up a new authentication realm in Keycloak | - created a new realm from the admin portal - modified and customized the realm from the admin dashboard |
Successfully added a new realm using Keycloak Docs | Success | 02/02 |
| EA6 | Set up a new authentication realm in Keycloak | - initial failure due to server not listening to IP 0.0.0.0 - success after modifying listening port |
Finally deployed the server on the VM and made it accessible from a remote browser | Initial Failure / Final Success | 05/03 |
Login remotely to Azure
Show roles in Active Directory
Running Keycloak locally
Accessing online deployed version
Internal Messaging
Carried out by Berat Baran Cevik
| Experiment | Title | Details | Results | Success and Failure | Date |
|---|---|---|---|---|---|
| EIM 1 | Exploring existing code on GitLab | I signed up to GitLab and joined the PEACH project group. I checked the repositories and latest commits to find out more about the project. | I had a clear idea about the componets of the project and I also noticed that some parts of the project had not started at all. | I successfully signed up to GitLab and joined the PEACH project group. I successfully accessed all previous code and saw the most recent commits. | 3/10 |
| EIM 1.1 | Browsing previous work on internal messaging system | After clearfying my role in the project I specifically looked for the internal messaging system repository in order to investigate previous wordone on this component. | I noticed that this repository did not exist and confirmed with the client that there was not any work done on this part of the project. | I successfully accessed all repositories and deducted that previous code on internal messaging system did not exist. I failed to investigate existing code because this part of the project had not been started yet. | 4/10 |
| EIM 1.2 | Finding out what technologies used previously for the entire project | I browsed all the repositories to find out which technologies, frameworks and programming languages used before we took over the project. | After the experiment I detected that HTML, CSS, JavaScript, Python and XML were used in the existing code. The other technologies used were Node.js, PostgreSQL, Docker and React. | Since GitLab does not have a functionality to show the used language as GitHub I had to open folders and files to detect the language and other technologies that were used. This probably caused me to overlook some of the technologies and languages used in the project. On the other hand, I managed to spot most of the important technologies used which helped me a lot with Experiment 2. | 7/10 |
| EIM 2 | Discovering technologies, programming languages and frameworks available for the project | I made a research on the Internet to find the most suitable and compatible languages, frameworks and other technologies for internal messaging system considering the experiment results from Experiement 1.2. I also got in touch with the UI super team to ask their opinion about preffered front-end technologies for this project. | I found that the most convenient technologies to use were JavaScript, Node.js and React. | Due to my lack of experience in many of the web frameworks I could not make perfectly a confident decision about which frameworks to use. I decided to use JavaScript, Node.js and React which turned out to be the right decision as project made progress. | 10/10 |
| EIM 3 | Creating and deploying a simple chat platform with Node.js, Express.js and Socket.io | I made a research on creating chat apps and how to deploy them to a cloud service. | I found some good tutorials on both creating and deploying chat apps. | I wasted some time looking at the chat platform tutorial which did not use JavaScript. I finally found some useful tutorials on both creating and deploying chat apps. | 18/10 |
| EIM 3.1 | Creating the chat platform | I made a research on creating chat apps using Node.js. | I followed two tutorials total to create a functional chat app. | I failed to create the features that I wanted in the first tutorial. Therefore, I moved on to the second tutorial and I sucesfully created a functional and real-time chat platform. | 22/10 |
| EIM 3.2 | Deploying the chat platform on Azure | I made a research on how to deploy Node.js apps on Azure. | I followed the tutorial and I had some difficulties with deploying the app but client and I decided to use an open source chat platformas the base of the internal messaging system. Then, I switched to that task. | I had some troubles with the tutorials I found but client and I decided to use an open source chat platformas the base of the internal messaging system. Then, I switched to that task. | 29/10 |
| EIM 4 | Discovering, choosing and deploying available open source chat platforms | I made a comprehensive research on available open source chat platforms considering the features, the technologies used, deployability and maintainability of the platform. | I decided to use Rocket.chat as our internal messaging system base. | I failed to eliminate some platforms at the beginning which made my decision harder among all these platforms. I successfully selected the best platform for PEACH internal messaging system in terms of features, technologies used, deployability and maintainability. | 8/11 |
| EIM 4.1 | Deploying chat on Azure | I tried to deploy the app manually using the tutorial on Rocket.chat's website and some other tutorials on the Internet. Afterwards I tried to deploy the app using Snaps and following a tutorial on Rocket.chat's website. | After trying to deploy the app manually configuring Ubuntu servers on Azure and failing many times, I successfully deployed the app on a Ubuntu server on Azure using Snaps . | I failed to deploy the app by configuring the Ubuntu server on Azure manually many times with different tutorials and different type of Ubuntu servers. I successfully deployed the app using Snaps and following the tutoria on Rocketchat's website. | 15/11 |
Login Page for the First Prototype
Chat Interface for the First Prototype
Login Page for Rocket.chat
Chat Interface for Rocket.chat
Collaborative Editing
Carried out by Georgiana Birjovanu
| Experiment | Title | Details | Results | Success and Failure | Date |
|---|---|---|---|---|---|
| ECE 1 | Implementation of Gobby | - allows real-time, lock-free collaborative text editing - it is needed to choose a private key and a certificate or to create a new pair in order to start sharing or co-editing the documents - it works to open an existing document or to create a new one (be exported as an HTML file or in its native format) - doesn't allow text formatting (*which is one of the requirements) |
I decided not to consider it as an available option | Failure | 28/10 |
| ECE 2 | Test of Etherpad | - web-based document editor, where users can collaborate on documents, leave comments and interact - presents its own integrated chat (*not a requirement) - text formatting features available - users can import existing documents into Etherpad and export them as HTML or different other files - it is written in JavaScript |
Could be considered as a possible solution | Success | 7/11 |
| ECE 3 | Implementation of Firepad | - allows synchronous document and code collaborative editing - uses Firebase as a backend - doesn't require a server-side code - could be implemented into a web app - text formatting is available Firepad represents a good start of creating a collaborative text editor component for our project. After having tested it, I concluded that most of our project's requirements could be easily implemented.The most important aspect consists in the fact that the integration of Firepad into a web app is possible. The reason for this is that the component has to be automatically used in various containers/templates of the future medical platform. |
It is most likely that Firepad will be the solution implemented for this project | Success | 8/11 |
| ECE 4 | Test of OnlyOffice | - real time co-editing and commenting on documents is available - it presents an online office package (word, spreadsheets and presentation are available in the browser) - can be installed on its own and to be integrated in any application through API |
Too complex for our project, as Office options are not required or needed | Failure | 20/11 |
| ** Other solutions considered and dismissed: MeetingWords and collabedit |
Test of Test of Etherpad
Implementation of Firepad
Test of OnlyOffice
