Filter root path according to the agent that makes the request

[gmgigi96]

No description provided.

[update-docs]

Thanks for opening this pull request! The maintainers of this repository would appreciate it if you would create a changelog item based on your changes.

[ishank011]

Can you confirm once that contexts from web requests are propagated here? We do pass the same context (https://github.com/cs3org/reva/blob/master/internal/http/services/owncloud/ocdav/get.go#L63) but let's confirm it once

Also please look at my review from the last PR

[ishank011]

I meant moving the IsUserAgentAllowed method to a separate package 😅

[dragotin]

Can anybody elaborate what that is used for? For me, this looks error prone and maybe incomplete, depending on what should be achieved. I think this kind of code will never catch all UserAgents (not talking about simply spoofing the UA) and should be avoided whenever possible.

[gmgigi96]

@dragotin The aim of this is to filter the root path view based on the agent that make the request. For example we would like to just view the home directory from the directory, while still see the home and shares from the sync client.

[gmgigi96]

@ishank011 I have just tested and the user agent from the http request is not propagated into the grpc requests

[lgtm-com]

This pull request introduces 1 alert when merging f2edb06 into 867d1e2 - view on LGTM.com

new alerts:

• 1 for Useless assignment to local variable

[ishank011]

Why don't we use this here?
grpc/grpc-go#1100 (comment)

server := grpc.Dial(grpc_server, WithUserAgent("user-agent",))

[gmgigi96]

Why don't we use this here? grpc/grpc-go#1100 (comment)

server := grpc.Dial(grpc_server, WithUserAgent("user-agent",))

I will leave a comment here to keep track on what we discussed yesterday and other thought I have after playing with user agents in GRPC.

Actually this is the way of specifying a user agent in a grpc call, that internally updates the outcoming metadata in the context when you will call a grpc method, and you can find the user agent in the incoming metadata in the context server-side. But, even if you specify your own user agent, this will be concatenated with the string "grpc-go/". I do not know if this can broke the library we use to parse the user agents, maybe not. But the main problem of using this approach is that for each time you want to get a grpc client for a service you need to specify the user agent that will do the request, if not specified, grpc automatically will set its default ("grpc-go/"). This means that we should modify all the methods in the pool pkg to receive a user agent. But I do not like this approach as we cannot cache anymore the grpc connection for each endpoint address, but we should cache also the user agent. In fact after a dial, there is no way to override it after creating a new connection (I tried also modifying the internal metadata of a context before a call, but apparently grpc reset it with the user agent passed to the Dial method).

So I preferred to define my own user agent token that will be managed internally by reva and not by grpc. With this approach we do not have the cons mentioned above. Of course the user agent log did not work, as it was reading the grpc user-agent metadata, and not the new one. Now it’s fixed and you should see the correct user agent in the log.