The use of Google ReCAPTCHA is now dropped in favor of rate limiting the number of save requests a user can create through the form (10/h).

Getting rid of ReCaptcha for save code now LGTM too.
I just wasn't sure that rate limit applies to Web UI submissions (e.g., will API requests come from our own IP? and if so, is that whitelisted?); I'm assuming that is what @anlambert plans to check.

In T1815#33533, @anlambert wrote:

I should have read django-simple-captcha doc, indeed its integration is not really straightforward for swh-web.
Currently, only the api endpoint for creating save requests is rate limited while the save code now form is submitted using Javascript
(validating input then setting the appropriate Django CSRF token before sending the POST request).
So without captcha, it will still be difficult for a dumb bot to spam us.
I would go for removing the captcha but add rate limiting to the form submission just in case.

FWIW https://grafana.softwareheritage.org/d/jScG7g6mk/objstorage-object-counts?orgId=1 is a (not great) implementation of this.

I should have read django-simple-captcha doc, indeed its integration is not really straightforward for swh-web.

As an alternative, we could just set the Django CSRF token on the form using a bit of Javascript code rather than the view sending it directly in the form, which would thwart most dumb bots (that's the "ReCAPTCHA alternatives for uncustomized spam > Javascript" section of the aforementioned article).

With the post-hoc moderation of Save Code Now requests, do we really need a captcha? Isn't the base rate limiting enough?

Django-simple-captcha works best out of the box using Forms or ModelForms. But the origin/save page is not rendered using forms, its plain HTML. One possible solution is to use a Form for origin save submission, the other is to write custom captcha template in and include it in the page. Which one did you have in mind?

In T1789#33370, @sandipbhuyan wrote:

Can we have the feature which will return the content of File Type, Language Type, and License not its URL

Can we have the feature which will return the content of File Type, Language Type, and License not its URL

I plan to add the following e2e tests-

1. Test basic webapp functionalities like 'sidebar', 'back-to-top'
2. Test home page displays positive stats for directories, authors,...
3. Test the origin-search with different combinations of checkboxes
4. Test basic functionality of directory view.
5. Test file being displayed (for some known format, maybe .txt)
6. Test error being displayed when invalid sha1 or unknown origin url

Closed by d355d8973205

These tests will be redundant with the end to end ones, so closing that task and prefer to rely on using cypress for frontend testing.

@shisus , I have tested cypress and the tool is indeed quite awesome !

No problem, I want to contribute to this project, so I'm looking where I would be able to work with.
Do you plan to add cypress in the web repository or Is it still a POC?
Is there a chance to work with you in setting up the cypress environment?

Thanks for pointing out the cypress tool, it looks pretty interesting.
Based on my understanding, it could be used to write and run unit tests but also end to end ones.

Hello everyone, I've some questions:

I think, we need to run the docker (with overridden swh-web) manually. And then run the selenium test cases. (I couldn't find a better approach)

In order to implement the unit tests, we will need the following node modules:

• mocha tests runner combined with an assertion library
• mocha-webpack to generate test bundles and execute them
• jsdom to emulate a browser environment in node
• json-global to ease jsdom use with mocha

We've discussed this back then, and decided in the end to leave it at the Django layer. Closing.

this is now done, at least based on IP addresses, we'll need (if it doesn't exist yet) a dedicated task for how to do it differently, e.g., using API keys