Provided apps need a scure view support flag

[AlexAndBear]

Describe the bug

To only show Collabora as assigned app for secure view in web(and dismiss the other apps), we need to have a secureViewSupported flag on the collabora app extension.

Blocker for:
owncloud/web#10765

Steps to reproduce

Expected behavior

A clear and concise description of what you expected to happen.

Actual behavior

A clear and concise description of what happened.

Setup

Please describe how you started the server and provide a list of relevant environment variables or configuration files.

OCIS_XXX=somevalue
OCIS_YYY=somevalue
PROXY_XXX=somevalue

Additional context

Add any other context about the problem here.

[micbar]

Where do you need that information to be present?

[AlexAndBear]

https://host.docker.internal:9200/app/list endpoint

[micbar]

Like that?

{
  "mime-types": [
    {
      "mime_type": "application/pdf",
      "ext": "pdf",
      "app_providers": [
        {
          "name": "OnlyOffice",
          "icon": "https://onlyoffice.ocis-wopi.latest.owncloud.works/web-apps/apps/documenteditor/main/resources/img/favicon.ico"
        },
        {
          "name": "Collabora",
          "secureView": true,
          "icon": "https://collabora.ocis-wopi.latest.owncloud.works/favicon.ico"
        },
      ],
      "name": "PDF",
      "description": "PDF document"
    },
    ]
}

[AlexAndBear]

Exactly 👍

[butonic]

This requites a CS3 api change. But app providers should not be able to just register and proclaim "hey I support secure view, trust me.". The registry should have a flag which the http /app/list endpoint can then render as a json property. Similar to how the default app flag works.

[butonic]

hm we might be able to sneak this in without a CS3 change...

[butonic]

• merge add secureview flag when listing apps via http cs3org/reva#4703
• merge add secureview flag when listing apps via http #9277
• bump reva in ocis

[butonic]

I'm not too happy with the solution. I still worry that someone might register an app via the CS3 API with the same name ... and that would allow him to get a token that grants him download permission.

Currently that is a theoretical problem, but still.

when getting the default app for a mimetype the static registry code also compares the address:

func (m *manager) GetDefaultProviderForMimeType(ctx context.Context, mimeType string) (*registrypb.ProviderInfo, error) {
	m.RLock()
	defer m.RUnlock()

	mimeInterface, ok := m.mimetypes.Get(mimeType)
	if ok {
		mime := mimeInterface.(*mimeTypeConfig)
		// default by provider address
		if p, ok := m.providers[mime.DefaultApp]; ok {
			return p, nil
		}

		// default by provider name
		for _, p := range m.providers {
			if p.Name == mime.DefaultApp {
				return p, nil
			}
		}
	}

	return nil, errtypes.NotFound("default application provider not set for mime type " + mimeType)
}

this allows admins to exactly configure which app provider is trusted (based on address).

but the address is removed when filtering the apps by user agent, which currently happens before checking if the app name matches the configured secure view app in the http appprovider:

	res := filterAppsByUserAgent(listRes.MimeTypes, r.UserAgent())

	// if app name or address matches the configured secure view app add that flag to the response
	for _, mt := range res {
		for _, app := range mt.AppProviders {
			if app.Name == s.conf.SecureViewApp {
				app.SecureView = true
			}
		}
	}

we could add the secureview check to the filterAppsByUserAgent call and use the app address:

// filterAppsByUserAgent rewrites the mime type info to only include apps that can be called by the user agent
// it also wraps the provider info to be able to add a secure view flag
func filterAppsByUserAgent(mimeTypes []*appregistry.MimeTypeInfo, userAgent, secureViewAppAddr string) []*MimeTypeInfo {
	ua := ua.Parse(userAgent)
	res := []*MimeTypeInfo{}
	for _, m := range mimeTypes {
		apps := []*ProviderInfo{}
		for _, p := range m.AppProviders {
			ep := &ProviderInfo{ProviderInfo: *p}
			if p.Address == secureViewAppAddr {
				ep.SecureView = true
			}
			p.Address = "" // address is internal only and not needed in the client
			// apps are called by name, so if it has no name it cannot be called and should not be advertised
			// also filter Desktop-only apps if ua is not Desktop
			if p.Name != "" && (ua.Desktop || !p.DesktopOnly) {
				apps = append(apps, ep)
			}
		}
		if len(apps) > 0 {
			mt := &MimeTypeInfo{MimeTypeInfo: *m}
			mt.AppProviders = apps
			res = append(res, mt)
		}
	}
	return res
}

BUT, in kubernetes the secureViewAppAddr is not fixed ... so we cannot configure it on an IP base.

we could use a domain name, but I don't konw if we register the appprovider with an IP address or a domain 👀

[butonic]

hm, in the collaboration service we register a service name:

	req := &registryv1beta1.AddAppProviderRequest{
		Provider: &registryv1beta1.ProviderInfo{
			Name:        cfg.App.Name,
			Description: cfg.App.Description,
			Icon:        cfg.App.Icon,
			Address:     cfg.GRPC.Namespace + "." + cfg.Service.Name,
			MimeTypes:   mimeTypes,
		},
	}

The reva grpc approvider registers the configured URL:

	pInfo, err := s.provider.GetAppProviderInfo(ctx)
	// ...
	pInfo.Address = s.conf.AppProviderURL
	// ...
	res, err := client.AddAppProvider(ctx, req)
	// ...

and the AppProviderURL

	AppProviderURL string                            `mapstructure:"app_provider_url"`

in our app provder revaconfig

					"app_provider_url": cfg.ExternalAddr,

is configured with

	ExternalAddr string  `yaml:"external_addr" env:"APP_PROVIDER_EXTERNAL_ADDR" desc:"Address of the app provider, where the GATEWAY service can reach it." introductionVersion:"pre5.0"`

which in our wopi deployment examples is also a service name:

      # use the internal service name
      APP_PROVIDER_EXTERNAL_ADDR: com.owncloud.api.app-provider-collabora

so ... this should work.

preparing PR

[butonic]

• set secureview flag based on addr cs3org/reva#4706
• set secureview flag based on addr #9289