Guest access

[papjul]

First of all, thank you for all your work on Gramps, it had helped so much for many years! This web API and Gramps.js are really what I missed, and this looks very promising!

I have one use case that maybe other people would be interested in, I don't think it has been implemented yet (maybe partially).

I would like to be able to share my tree with everyone on my personal website but not allow anyone to edit it.

Basically, there would be two kind of access:

• Guest access: it would be similar to DISABLE_AUTH=True but the data would be in readonly for them, and no private or living data would be shown. This would allow sharing our personal tree with everyone that may be interested only by our common (old) ancestors, by sharing a link to a specific person, for example.
• Logged access: it would still be possible to access with an account to private and/or living data. In my use case, I wouldn't allow them to edit data as I manually review everything in a separate copy on my computer, but other people may have a different use case than me, and allow a write access.

On homepage, you would have the log in form followed by a button "Continue as guest" or something like this.

What do you think?

[DavidMStraub]

Hi! I see your point, there are two things to distinguish here:

1. Read-only access without authentication
2. Read-only access with authentication

2 Is already possible. Please see here for the documentation of the user roles. If you create a user with "Guest" role, they can read everything that is not set to "private", but not edit anything.

If you are really sure you want to do 1, it is possible with a work-around; simply create a "Guest" account and publish the credentials on your website.

However, it was a conscious design decision of Gramps Web API not to allow unauthenticated access. Its main purpose is to share the all geneaological research data, e.g. with family members or fellow researchers. There are several reasons why I would not want to implement unauthenticated access (DISABLE_AUTH=True is obviously just for development/testing):

• There are already plenty of excellent solutions for sharing a read-only family tree, or parts of it, with the public, e.g. narrated web or dynamic web. They have the big advantage that they can be generated based on filters.
• When Gramps is used to its full potential - i.e. storing all genealogical research data - in my experience it is nearly impossible to ensure that all data can be legally published on the public Internet, especially with GDPR in Europe.
• Given there is the possibility of a public guest account, I also don't see the benefit justifying implementing this major change of the authentication system, that could even increase the likelihood of security i
• ssues.
• It is much more difficult to deal with robots, crawlers, etc., when the API is totally open.

I hope this explains the rationale a bit better.

[papjul]

There are already plenty of excellent solutions for sharing a read-only family tree, or parts of it, with the public, e.g. narrated web or dynamic web. They have the big advantage that they can be generated based on filters.

I tried generated reports, webtrees and others, but they were really not user-friendly, compared to the modern Gramps.js. If I missed a good tool, I would happy to use it, since my use case is really readonly so it would be best indeed ;)

When Gramps is used to its full potential - i.e. storing all genealogical research data - in my experience it is nearly impossible to ensure that all data can be legally published on the public Internet, especially with GDPR in Europe.

That's why I wanted to exclude all living ones. I probably need to make all of them private to be able to use the role 0 safely.

Given there is the possibility of a public guest account, I also don't see the benefit justifying implementing this major change of the authentication system, that could even increase the likelihood of security issues.

In that case, for a more simple technical solution, maybe make the "Continue as guest" button log ourself as the designated guest account? (instead of writing the user/password and asking guests to enter them)

[DavidMStraub]

That's why I wanted to exclude all living ones. I probably need to make all of them private to be able to use the role 0 safely.

Yes, unfortunately, that's the only way to achieve that right now (I also do it like that). The problem is that Gramps' living filter only applies to people and not to media objects etc., so I am not sure how to even implement it.

In that case, for a more simple technical solution, maybe make the "Continue as guest" button log ourself as the designated guest account? (instead of writing the user/password and asking guests to enter them)

I would strongly advise against that as it would hide to the user the fact that they have just logged into an app (with the token stored in the browser etc.). If they share a link they would be surprised that somebody else clicking on the link won't be able to open it.

Again, even if this (sharing credentials publicly) is possible, I don't think it should be officially endorsed/supported/recommended. There are subtleties; for instance, without authentication, normally you can only access the token and password reset endpoints and they have a 1 call/second rate limit to avoid abuse. But all the other endpoints (that require authentication) don't have rate limits, so a malicious user could flood them. This is just the first example I could think of and I'm not saying it's not possible to fix it, but when the whole app has been developed with the "1 account per person" condition in mind, I think there can be risks opening it completely.

[DavidMStraub]

I will close this issue but feel free to add additional comments.

[papjul]

Sure, in case someone has the same issue, here is my current solution: I'm exporting a filtered GEDCOM from Gramps, and importing it regularly in Webtrees with the JustLight theme.

I initially used the dynamic web report from Gramps first but then noticed that links to individuals kept changing so when I gave a link to an individual to someone, few days later, it pointed to a completely different individual because the dynamic web report generate random IDs, while in Webtrees, links use the GEDCOM ID so it always stay the same link ;)