GitLab Apps

Description

Externals services have limited options for integration and cant not provide seamless UX to users pressuring GitLab to be the all in one for everything. (koding.com example).

Proposal

GitLab Apps Rather than often incomplete integration via webhooks or tightly coupled integration of adding the entire solution to the stack koding GitLab Apps provides intimate integration and seamless UX with loosely coupled and distributed systems.

Lose coupling and integration of distributed systems via messaging is far more scalable (systems, users, market) than one-db to rule them all. Seamless UX can be achieved by allowing GitLab Apps to hook int to the page render with their own web components.

Think of the SalesForce AppExchange or the Google Apps Market Place.

Hypothetical examples:

• Koding.com, Cloud9, or Kanboard GitLab Apps could integrated on events across multiple GitLab services, the UI, CI, Issues, MR....
• Mermaid Diagrams GitLab App could merely load the js lib.
• CloudFlare GitLab App could provide an easy interface for managing CloudFlare over its API in front of GitLab Pages and expose an env var to CI
• SNS GitLab App could through events to AWS SNS and expose a per project SNS Topic field with the webhooks settings.
• CI on AWS GitLab App could take AWS credentials and deploy an auto scale CI services in my AWS account.
• Code coverage app could display istanbul reports on a project and in MR.
• Gemfury account could provide repo integration first class alongside GitLab Docker registry.
• Email Gateway App could provide email to issue handling akin to Jira Service Desk.

Yes, all the above could be done by adding the functionally built into GitLab. But going back to SalesForce - the CRM is far below awesome. The success of SalesForce is the AppExchange.

GitLab could run a container service for apps, but I am thinking more along the lines of apps provide their own compute resources, integrates with GitLab events, and can modify the UI.

Mentioned in issue gitlab-com/infrastructure#403 (closed)

BitBucket Connect is a good example of way to allow untrusted third-parties the ability to extend GitLab's interface in a secure manner (even on their hosted service at BitBucket.com).

From what I can gather, BitBucket allows app developers to set locations on a page where an iframe will be injected to load their app. The app receives a JWT token to communicate to the BitBucket server's API and defines certain webhooks to receive. The apps themselves are hosted by the developer, not by BitBucket. The developer defines what permissions the app needs and the user needs to approve them.

Edit: Atlassian Connect is the encompassing feature to extend Atlassian products (including BitBucket) without directly interfacing with the Atlassian code.

Injecting an iframe sounds like a terrifying technical decision, I would be opposed for security as well as UX reasons.

I like the BitBucket Connect example, but GitLab Apps could be trusted from a marketplace or app store rather than anything and could have UX integration more along the lines of an Odoo or Drupal module than an iframe.

(Using the terminology "extension" here as a general term for what the issue suggests, in addition to other similar concepts found in applications such as plugins, addons, etc.)

@tom.davidson The problem with something like a Odoo addon or Drupal module is that those extensions run as trusted code alongside GitLab on the server. This has several downsides:

• The server administrator has to place absolute trust in the quality of the extension. A security vulnerability in the extension could very well mean a vulnerability in the entire GitLab installation. Additionally, the admin must trust that the extension does not cause any data corruption or bugs that prevent other users from using GitLab. As a system administrator myself, I would be very hesitant to install such code onto my server.
• Such an extension would need to have API compatibility with GitLab's code, including supporting matching Ruby versions. GitLab would need to commit to exposing a stable Ruby API for extensions to connect to and go through a lot of effort to make sure changes don't break extensions.
• Extensions could only be written in Ruby. I imagine that many companies would be interested in creating extensions for their products as well as internal processes (I know of a few things that I would be interested in creating). Limiting extensions to Ruby would greatly increase the barrier of entry for creating extensions, so much so that many companies might not even bother. By implementing extensions in such a way that does not require a specific language, developers are able to create extensions much more easily.
• The extensions would need to be installed on the server as executable code, meaning that they could only realistically be selected by the system administrator, meaning that they could not be used on GitLab.com, where a significant size of the userbase is. It would also mean that the GitLab team could not dogfood the extensions, increasing the chances of bugs occuring in the implementation of the feature.

@connorshea I understand the hesitance. The implementation and it's design would need to be examined very carefully. However, I think you misunderstand the security impact of properly injecting an iframe. This StackOverflow answer discusses the security impact.

The IFRAME element may be a security risk if your site is embedded inside an IFRAME on hostile site.

Not relevant for this issue, as the apps would be embedded inside GitLab, not the other way around.

IFRAME element may be a security risk if any page on your site contains an XSS vulnerability which can be exploited.

This can be mitigated with X-Frame-Options: DENY (supported on nearly all browsers). An XSS within GitLab would cause more problems anyways, as much of GitLab's functionality could be accessed from ajax requests from the injected malicious script.

Content from can initiate top level navigation by default

This can be prevented via the use of the sandbox attribute, which is supported by nearly all browsers.

Accidentally submitted early. Will finish reply in new comment.

@connorshea

I would be opposed for [...] UX reasons

• There is the UX issue of the URL not changing when the content within the iframe is navigated (when the iframe is acting as a whole page, assuming this functionally is supported). If changing the URL would be desired, it would be possible to have the iframe request a URL change (but only allowing the app to change the URL to a subresource/subdirectory) and to pass the URL to the iframe when it loads.
• In order to make sure that the user is aware that the content is an iframe and is not a part of GitLab, the iframe could be disabled and not be loaded until the user approves:

• In order to match GitLab's style, GitLab would need to expose some UI library for the apps to use. Atlassian Connect provides the Atlassian User Interface Library for add-ons to use.
• To communicate with the hosting page, the iframe could be provided with a script that provides a communication bridge. Atlassian Connect uses window.postMessage to communicate across the iframe boundary with a JS script that provides an API to access parts of the host page.

@rabbitfang GitLab Apps should be able to exploit interfaces and negate the need for Ruby, installing code on the server, and for complete trust from the GitLab server admin. Again, think the SalesForce and Google Apps comparison. I should not have used Odoo and Drupal modules in the comparison so it would not confuse this issue, but I meant for those to suggest a level of seamless UX that could be hard to achieve with iframe.

I am not against ruby in anyway, but what I am proposing is the ability for a service provider integrate beyond webhooks and a menu link. The service provider runs their own code on and resources. "GitLab could run a container service for apps, but I am thinking more along the lines of apps provide their own compute resources, integrates with GitLab events, and can modify the UI."

The GitLab server admin does not need to trust the service provider at all, or even be aware of the 3rd party extension (but I do think a marketplace or directory would be valuable to users) and the admin only needs to trust that that the GitLab service interfaces and security will function properly. As a GitLab (lets say gitlab.com) user I can extend my authorization for other apps (we can do that right now with webhooks). The other apps gain system access with my credentials not through server admin trust.

All backend integrations should take place over an api, from setting an env var value for CI to config of a webhook, to issue management... in not being creative at the moment, but everything. The API can rest and maybe graphql #22753 (closed) but there should also be an interface to share events. Im not sure how much of GitLab uses shared database module but I expect it to be more on the monolithic side rather than microservices side. API first and events will facialyt at GitLab's internal apps even if the driver for this proposal is for external apps.

Front end integrations can all be client side with dynamic and lazy loading. This inverts some of the page rendering and state control away from the server, but this inversion is the trend for modern webapps and is not unique to this proposal. As a user I pick and choose what GitLab Apps I want to use. This creates the authorization to the APIs for the backend but also adds a JavaScript module to my UI. Again the module, like the rest of the client-side code, does not have to be trusted by the GitLab server admin, it uses my user credentials, I as user extent the trust and the module can not to any damage that I could not already do.

The GitLab App's JavaScript module can manipulate whatever parts of the UI it wants. A developer could create one right now and have it loaded via a proxy or with a browser dev tool. It would be hackish and fragile. This proposal includes creating an interface for such JavaScript UI modules so they do not have to be hackish or fragile. Contentful provides and SDK to do just this and of course there are Google App Scripts - in addition to the app marketplace/exchagne examples out there.

Added feature proposal label

moved to gitlab#6428

Hey! 👋

GitLab is moving all development for both GitLab Community Edition and Enterprise Edition into a single codebase. The current gitlab-ce repository will become a read-only mirror, without any proprietary code. All development is moved to the current gitlab-ee repository, which we will rename to just gitlab in the coming weeks. As part of this migration, issues will be moved to the current gitlab-ee project.

If you have any questions about all of this, please ask them in our dedicated FAQ issue.

https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

You can also find more information here:

• https://gitlab.com/gitlab-org/gitlab-ee/issues/13304
• https://about.gitlab.com/2019/08/23/a-single-codebase-for-gitlab-community-and-enterprise-edition/

Frequently Asked Questions

For an up to date list of questions and answers, please take a look at https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

What will we do with the repository names?

https://gitlab.com/gitlab-org/gitlab-ee/ will become https://gitlab.com/gitlab-org/gitlab, and https://gitlab.com/gitlab-org/gitlab-ce will become https://gitlab.com/gitlab-org/gitlab-foss.

Why rename gitlab-ce to gitlab-foss?

Using "gitlab" and "gitlab-ce" would be confusing, so we decided to rename gitlab-ce to gitlab-foss to make the purpose of this FOSS repository more clear

I created a merge requests for CE, and this got closed. What do I need to do?

You will need to create a merge request at https://gitlab.com/gitlab-org/gitlab-ee/. This link will eventually redirect to https://gitlab.com/gitlab-org/gitlab.

How does the licensing work in this new setup?

Everything in the ee/ directory is proprietary. Everything else is free and open source software. If your merge request does not change anything in the ee/ directory, the process of contributing changes is the same as when using the gitlab-ce repository.

Will you accept merge requests on the gitlab-ce/gitlab-foss project after it has been renamed?

No. Merge requests submitted to this project will be closed automatically.

Will I still be able to view old issues and merge requests in gitlab-ce/gitlab-foss?

Yes.

How will this affect users of GitLab CE using Omnibus?

No changes will be necessary, as the packages built remain the same.

How will this affect users of GitLab CE that build from source?

Once the project has been renamed, you will need to change your Git remotes to use this new URL. GitLab will take care of redirecting Git operations so there is no hard deadline, but we recommend doing this as soon as the projects have been renamed.

Where can I see a timeline of the remaining steps?

https://gitlab.com/gitlab-org/gitlab-ee/issues/13304

Will community contributions submitted to the new "gitlab" repository be available in the new gitlab-foss repository?

Yes, these changes will be synced to gitlab-foss automatically, several times per day.

locked this issue