Connect the webserver to a registration service #10
reinhard
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Because we might not be able to carry the load of accepting any and all queries, we can require the users to register their project before they can request badges.
Are you thinking about an external registration service, or a web page of our own where people have to register their repository before they can access the API?
@max.mehl can answer that question better, I think. Extract from e-mail:
Yes, let me quote our email conversation
The file repos.json, as created by the forms app, is attached.
This would mean that we have to parse the (whole!) JSON file each time a check for a new repository is requested, and then create a record in our SQLite database.
Maybe it could be much easier if the forms server was able to store the data directly in our SQLite database, so we can skip the whole step of writing and parsing the JSON file. Would you agree?
Thinking about it again, we have defined some requirements e.g. about what we accept as a repository, this is something that the forms server will not be able to check. In the end, people will be able to register a repository URL in a format not supported by us, and only when they try to use the API, they will receive an error message telling them about that.
Considering on the other hand that a double opt-in is not rocket science, I am increasingly unsure whether our case here is a good application for the form server, or we'd be better off by implementing the registration here in a clean and self-contained way.
You have a good point on the invalid format. How about making this API the entry point, checking the requirements, and only then sending a request to forms? This would outsource the opt-in part and also the storage of personal data (GDPR!) to this service.
This would not solve the problem of constantly reading the JSON file though, but I don't consider this a great performance impact TBH.
But I cannot fully evaluate the technical dimensions, so this is only my 2 cents ;)
I see your point about outsorcing the storage of personal data. When thinking about this further, I got to the following idea:
User fills in a form at
https://api.reuse.software/registerwith the fields "email address" and "repository URL". The last is checked according to our rules.Server sends email to the given address with a confirmation link like
https://api.reuse.software/confirm?url=<repository-url>&signature=<signature-hash>.Server does not store any data.User clicks on confirmation link in email, gets a page with button to confirm registration.
Server enters the confirmed URL in the database and starts the first lint.
I guess that's kind of "least complexity solution". What do you think?
Sure, that would work. The benefit of using forms would indeed be that we actually store data. Perhaps we need a way to communicate with the repository owners (or at least those that have entered the projects), e.g. because the API changed.
The advantage of using forms would be that personal data resides where it is stored anyway.
Okay, I was not aware that we actually want to store the registration data.
Some caveats you might want to be aware of:
Thank you for your thoughts!
True. Can the api make the first sanity checks here?
Also true. I have responded to that issue with an idea how it could be easily fixed. In general, we don't need to hide that the FSFE is behind REUSE, so that's fair ;)
Yes, the form on api.reuse.software can make some sanity checks, actually that would be the same checks as would be done in my proposal step 1, and that would include a check for duplicates.
Excellent. So weighing the pros and cons, would you rather choose:
Personally, I am not convinced that it makes much sense to store the email address which registered the project. My feeling is that at some point in a few years, when we might really have a use case where we'd need to contact the developers, more than 50% of these email addresses would no longer work or not be involved in the project any more.
About the double opt-in procedure, I maintain the point that it can be solved near-trivially.
So below the line, I have the impression that the benefit of storing the registrant's data and reusing an existing double opt-in framework is not worth the increased complexity arising from involving the form server.
Note this is my personal input, I can live with whatever the project leads decide.
@carmenbianca @florian.vuillemot what do you think?
I wish I had an educated opinion, but I'm a little bit in the dark about the functionality of the forms project. I agree with @reinhard however that we probably should not store personal information.
After a lot of thinking, I would - personally - still prefer to use forms because I know the service, and because we can contact all repo owners if something changes dramatically in the first months.
But let me try to find a compromise:
This way, we might not catch all submitters, but still have some way to reach interested parties. Not only for technical messages, but perhaps also for large updates of REUSE in general.
What do you think?
We could do this, but we could also use a simple mailing list for the voluntary sign up for further infos.
(You know I love the form server as much as you do, but I guess for some purposes it's just not the best tool...)
Hm, this will decrease the amount of people we can contact yet again I'm afraid, since mailing lists are a high threshold...
Didn't we have some magic that allows us to automatically add somebody to a mailing list? So we could just add a checkbox to the registration form "[x] keep me informed about this service (recommended)"? And the user just has to do the standard mailman subscription confirmation?
I worked on this for the Spread the Word page, but I failed with my first tries. The XSRF protection makes a few things more complicated, and there seems to be another protection in place which I was not aware of. It's on my todo list to try it again.
Please let's try it as I proposed here: #10 (comment)
The existing forms app is not completely fitting for this, as the text suggests that it's about registration of a project, and requires its URL, but we can change it later.
@max.mehl just to avoid misunderstandings: should the signup on forms for future information about the project require double opt-in?
Yes. All email addresses we send mails to should be somehow confirmed, otherwise we'll run into GDPR issues. Since the registration with forms is separate from this API's registration, I'm afraid we have to ask interested users twice for email confirmation.
I'm working on this, will issue a PR once the other open PR is merged (to avoid conflicts).