GraphQL: Can't read page.single with there is read permission on page

[codevin]

In the page-component pull request which I submitted, GraphQL query is used to read the Component page. It fails for general user because it tests 'manage.page' or 'delete.page' permissions.

Shouldn't it also include 'read.page' also? Because if guest can read a page, GraphQL should also be able to read it.

File: https://github.com/Requarks/wiki/blob/master/server/graph/resolvers/page.js
Function:

  async single (obj, args, context, info) {
      let page = await WIKI.models.pages.getPageFromDb(args.id)
      if (page) {
        if (WIKI.auth.checkAccess(context.req.user, ['manage:pages', 'delete:pages'], {
          path: page.path,
          locale: page.localeCode
        })

[Smankusors]

Are you sure your global permission and page rules are correct? You cannot just set global permission without page rules.

[codevin]

I will check once more. But guest user can view the pages both where component is defined and used. That means read permission is there, right? Even otherwise, just looking at logic of the code, why would you check manage/delete when graphql is just reading? ~V

…

On Fri, 15 May 2020, 22:57 Antony Kurniawan, ***@***.***> wrote: Are you sure your global permission and page rules are correct? You cannot just set global permission without page rules. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1895 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AASE2SB3HCJIJJVFSNENAVDRRV3QDANCNFSM4NBX4UUQ> .

[NGPixel]

The single endpoint does not check for page rules, only permissions, because it's meant to be used by the admin panel, which is why there's no read:pages permission.

Adding the read:pages permission would require the page rules to be checked and some properties to be marked as manage only.

[codevin]

Could you revisit the assumption that GraphQL is only used by admin users or for admin purposes only?

Because page-components depends on some API way to access the source of page. I guess this is important design decision.

My point is that page-components will enable more interesting functionality within wikis (like introducing widgets like weather, show table data and so on). It won't work without this capability as of now.

[NGPixel]

That's not what I said. This specific resource is for admin. Many other GraphQL resources are used by normal users and guests.

What is your use case for querying the page source?

[codevin]

Page components feature, that allows users to define vue components in wiki page, and use them elsewhere in wiki. See the submitted pull request: #1865

…

On Sat, May 16, 2020 at 11:25 PM Nicolas Giard ***@***.***> wrote: That's not what I said. This specific resource is for admin. Many other GraphQL resources are used by normal users and guests. What is your use case for querying the page source? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1895 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AASE2SHTOCQWHSHEASSUYADRR3HP7ANCNFSM4NBX4UUQ> .

[NGPixel]

I don't think using pages to store Vue components is the best idea. It would be very inefficient to fetch and store them in this manner. I would rather have a dedicated table and resolvers. And possibly inject them directly on the page server-side so they load instantly on the client.

[codevin]

It is wiki. Give power to users! If security is taken care of. You can't possibly consider all possible situations that users may want to read from. Also, it is not only for tables. For e.g. we could allow sharing of styles and use them to style content in other pages.

…

On Mon, May 18, 2020 at 10:19 AM Nicolas Giard ***@***.***> wrote: I don't think using pages to store Vue components is the best idea. It would be very inefficient to fetch and store them in this manner. I would rather have a dedicated table and resolvers. And possibly inject them directly on the page server-side so they load instantly on the client. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1895 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AASE2SD6PNLZYDJ2W2MFZNTRSC463ANCNFSM4NBX4UUQ> .

[codevin]

Can we at least have client side plugins, so those who are interested can have this capability?

I will open a feature request in feedback to get some votes.

[NGPixel]

I'm all for it, I just don't agree with the suggested implementation.

A feature request where the implementation can be discussed would be best.

[codevin]

If a page contains JSON data table, and some markup to select style of table, isn't it a clean design? (Here the styles (and table renderer) may come from server config or from another page in which we define a Vue component. The latter is not a content page. It needs to be a wiki page because users can then create and reuse the plugins, learn from different sites, from each other etc. And one may use a simple alternate template to fetch data, in case someone wants to data scraping.

…

On Fri, 25 Sep 2020, 18:50 Maxime Chambonnet, ***@***.***> wrote: My 2cents as a big noob in webdev, is that wikimedia made a fundamentally wrong design decision with wikitext, which is so garbage that virtually all the content ever produced in wikipedia is forever irrecoverable. I am exaggerating, but I don't think having vue components defined in userspace html is a great idea. It would be in same the trend of making the page contents not reusable elsewhere without significant effort. If the user is tech-savvy enough and wants a custom component, make her/him add it as a wikijs extension and call it from the page content. This will also encourage contributions. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1895 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AASE2SF2ASAAXSJ3J4CYHMDSHSKI5ANCNFSM4NBX4UUQ> .