Project

General

Profile

Actions

tickets #124727

closed

Progress API

Added by ilausuch about 1 year ago. Updated about 1 year ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
2023-02-17
Due date:
% Done:

0%

Estimated time:

Description

Hi,

I am engineer at SUSE at the department of QE. I am working in a project that extracts information from the progress using the API to generate metrics. It usually do several requests (for the project I am testing >400) in a sort period of time.

I think my IP was blocked because using different VPNs IPs I can continue calling to the API and continue my work. I checked that should be some sort of limitation of number of queries I could perform or request to the machine. I hope that in the future this project will be working in a production environment with different projects.

Is there anyway to solve this situation? And prevent that when we have the system in production will be blocked?

The project is this one:
https://github.com/ilausuch/project_management_statistics
This is also a Hackweek project.

I put in copy to my manager in case you need to ask him about some authorisation. He knows what is objective of this project

Thank you
Best regards,


Related issues 1 (0 open1 closed)

Is duplicate of openSUSE admin - tickets #124559: Banned ip for progress?Closed2023-02-15

Actions
Actions #1

Updated by pjessen about 1 year ago

Actions #2

Updated by pjessen about 1 year ago

  • Private changed from Yes to No
Actions #3

Updated by pjessen about 1 year ago

Suggestion- why don't you just reduce the query frequency to what the system will accept? that seems to me to be the minimally invasive approach.

Actions #4

Updated by crameleon about 1 year ago

This limitation was introduced on the proxy servers in front of progress.opensuse.org some weeks ago after someone caused a successful denial of service (attack?). The rate limit on the host firewall was considered an easy solution and the numbers chosen were deemed a reasonable choice between keeping attackers out and regular humans in. We did not consider the service being used for intensive API queries.

Unfortunately more sophisticated solutions (such as load balancing or a web application firewall) would require more planning and work to implement - and just disabling the limitation again is prone to causing more disruptions of service sooner or later.

Actions #5

Updated by ilausuch about 1 year ago

Yes, I think for now I could add delays to ensure not to raise the limits. On the first iterations this will be slow, but let's see

Actions #6

Updated by crameleon about 1 year ago

  • Status changed from New to Closed

Closing, feel free to reply and reopen if you need further assistance.

Actions

Also available in: Atom PDF