## Description
This PR adds rate limiting functionality to datasource test API. The
rate limiting configuration is added in such a way that if test API
receives more than 3 failed authentication requests for the same host
name within 5 seconds, It will block this hostname for the next 5
minutes, so that brute force attack can be stopped.
Unit test for this will be covered in another PR. Refer #27742
Currently this PR covers for postgres only, will need to extend the
implementation for all plugins. Refer #27737
#### PR fixes following issue(s)
Fixes#27736, #27739, #27744
> if no issue exists, please create an issue and ask the maintainers
about this first
>
>
#### Media
> A video or a GIF is preferred. when using Loom, don’t embed because it
looks like it’s a GIF. instead, just link to the video
>
>
#### Type of change
- Chore (housekeeping or task changes that don't impact user perception)
>
>
>
## Testing
>
#### How Has This Been Tested?
> Please describe the tests that you ran to verify your changes. Also
list any relevant details for your test configuration.
> Delete anything that is not relevant
- [x] Manual
- [ ] JUnit
- [ ] Jest
- [ ] Cypress
>
>
#### Test Plan
> Add Testsmith test cases links that relate to this PR
>
>
#### Issues raised during DP testing
> Link issues raised during DP testing for better visiblity and tracking
(copy link from comments dropped on this PR)
>
>
>
## Checklist:
#### Dev activity
- [x] My code follows the style guidelines of this project
- [x] I have performed a self-review of my own code
- [x] I have commented my code, particularly in hard-to-understand areas
- [ ] I have made corresponding changes to the documentation
- [x] My changes generate no new warnings
- [ ] I have added tests that prove my fix is effective or that my
feature works
- [ ] New and existing unit tests pass locally with my changes
- [x] PR is being merged under a feature flag
#### QA activity:
- [ ] [Speedbreak
features](https://github.com/appsmithorg/TestSmith/wiki/Guidelines-for-test-plans#speedbreakers-)
have been covered
- [ ] Test plan covers all impacted features and [areas of
interest](https://github.com/appsmithorg/TestSmith/wiki/Guidelines-for-test-plans#areas-of-interest-)
- [ ] Test plan has been peer reviewed by project stakeholders and other
QA members
- [ ] Manually tested functionality on DP
- [ ] We had an implementation alignment call with stakeholders post QA
Round 2
- [ ] Cypress test cases have been added and approved by SDET/manual QA
- [ ] Added `Test Plan Approved` label after Cypress tests were reviewed
- [ ] Added `Test Plan Approved` label after JUnit tests were reviewed
---------
Co-authored-by: “sneha122” <“sneha@appsmith.com”>
## Description
- Add changes to address the`StaleConnection` exception caused by MySQL plugin.
- Update MySQL driver version.
- Other refactor changes not related to the main issue:
- Explicit empty constructor definition is replaced with Lombok annotation for all error messages class.
- A base class is created for plugin error messages class to store all common error messages.
- Fix Indentation.
## Description
This PR fixes :
- the functionality of placeholder for the key value array control which
was earlier accessing `placeholderText` key from a wrong path for host.
- Added placeholders for different datasources as well
## Description
> In this pr, loginTimout param is added to datasourceProperties map of
HikariConfig object so that the ssl peer is verified within the UI
timeout limit
> This fixes the issue:
https://github.com/appsmithorg/appsmith/issues/22035Fixes#22035
## Type of change
- Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
> Add a Snowflake DB with wrong account name as provided in the related
issue. Test the datasource, and wait for the error to come up. Error
should show up on UI in ~15 seconds with message that ssl peer identity
validation has failed.
- Manual
- Jest
- Cypress
### Test Plan
> Add a Snowflake DB with wrong account name as provided in the related
issue. Test the datasource, and wait for the error to come up. Error
should show up on UI in ~15 seconds with message that ssl peer identity
validation has failed. A correct account id should be instantly
validated. This is because with the account id provided in the issue,
the error took 60 seconds to occur which now has been reduced to 15
seconds.
## Checklist:
### Dev activity
- [x] My code follows the style guidelines of this project
- [x] I have performed a self-review of my own code
- [x] I have commented my code, particularly in hard-to-understand areas
- [ ] I have made corresponding changes to the documentation
- [x] My changes generate no new warnings
- [ ] I have added tests that prove my fix is effective or that my
feature works
- [x] New and existing unit tests pass locally with my changes
- [ ] PR is being merged under a feature flag
### QA activity:
- [ ] Test plan has been approved by relevant developers
- [ ] Test plan has been peer reviewed by QA
- [ ] Cypress test cases have been added and approved by either SDET or
manual QA
- [ ] Organized project review call with relevant stakeholders after
Round 1/2 of QA
- [ ] Added Test Plan Approved label after reveiwing all Cypress test
## Description
- Add infra to re-format error messages.
- Re-format error message for test datasource failure due to (1) bad endpoint (2) timeout
Fixes#21782
Solves a single thing in the build configurations, resulting in a few
wins.
1. Reduced number of warnings in the output.
1. In release branch:
```
mvn clean package -DskipTests | grep --fixed-strings --count '[WARNING]'
3233
```
1. In this PR's branch:
```
mvn clean package -DskipTests | grep --fixed-strings --count '[WARNING]'
172
```
2. All uber-jar files are shaded twice, currently. Once with the default
execution of `maven-shade-plugin`, and again with the `shade-plugin-jar`
execution in these `pom.xml` files. This is double-work, and is the
cause of most of the warnings we see.
1. This `shade-plugin-jar` was added to have the plugin information
included in the `/META-INF/MANIFEST.MF` file, since we can't configure
the default execution of the shade plugin (it comes to us from Spring
Boot).
2. Instead, we switch to configuring plugin information in a
`/plugin.properties` file.
3. Previously, we used `/plugin.properities` for plugin information in
dev time, and `/META-INF/MANIFEST.MF` in production. This PR will change
it so that we use `/plugin.properties` all the time. We configure PF4J
with a custom plugin manager to achieve this.
3. Moved all `plugin.properties` into `src/main/resources`, so that they
land up in the root of the final jar files. But this means, during
development, loading the plugin fails since it looks for a
`plugin.properties` at the root of the plugin module, i.e., next to the
`src` folder.
1. For this, in the custom plugin manager class, we change where we look
for the `plugin.properties` file during development mode. In this mode,
we look at the `target/classes/plugin.properties` file, which is where
maven saves this file, taken from
`src/main/resources/plugin.properties`.
2. This also solves the duplication of the plugin properties that's
currently present, between `plugin.properties` and the `<properties>`
section of `pom.xml` files.
Here's the shade plugin's default execution and configuration, from
Spring Boot:
https://github.com/spring-projects/spring-boot/blob/v3.0.1/spring-boot-project/spring-boot-starters/spring-boot-starter-parent/build.gradle#L174.
## Description
This PR updates the error logs
- Establishing a consistent format for all error messages.
- Revising error titles and details for improved understanding.
- Compiling internal documentation of all error categories,
subcategories, and error descriptions.
Updated Error Interface:
https://www.notion.so/appsmith/Error-Interface-for-Plugin-Execution-Error-7b3f5323ba4c40bfad281ae717ccf79b
PRD:
https://www.notion.so/appsmith/PRD-Error-Handling-Framework-4ac9747057fd4105a9d52cb8b42f4452?pvs=4#008e9c79ff3c484abf0250a5416cf052
>TL;DR
Fixes #
Media
> A video or a GIF is preferred. when using Loom, don’t embed because it
looks like it’s a GIF. instead, just link to the video
## Type of change
- New feature (non-breaking change which adds functionality)
## How Has This Been Tested?
- Manual
- Jest
- Cypress
### Test Plan
### Issues raised during DP testing
## Checklist:
### Dev activity
- [x] My code follows the style guidelines of this project
- [x] I have performed a self-review of my own code
- [x] I have commented my code, particularly in hard-to-understand areas
- [ ] I have made corresponding changes to the documentation
- [x] My changes generate no new warnings
- [x] I have added tests that prove my fix is effective or that my
feature works
- [x] New and existing unit tests pass locally with my changes
- [x] PR is being merged under a feature flag
### QA activity:
- [ ] Test plan has been approved by relevant developers
- [ ] Test plan has been peer reviewed by QA
- [ ] Cypress test cases have been added and approved by either SDET or
manual QA
- [ ] Organized project review call with relevant stakeholders after
Round 1/2 of QA
- [ ] Added Test Plan Approved label after reveiwing all Cypress test
---------
Co-authored-by: subrata <subrata@appsmith.com>
This upgrade takes care of our move to JDK 17, Spring Boot 3.0.1 and a
few other security upgrades along the way.
Fixes#18993
TODO:
- [x] Check CI changes for Java 17
- [x] Check vulnerability report
- [x] Mongock needs an upgrade
- [x] Add JVM args at all possible places for exposing java.time module
- [x] Add type adapters everywhere / use the same config for type
adapters everywhere
* Changes to testDatasource interface method and archive flow
* Tests for plugin level testDatasource implementations
* Added test for refreshing cache on deleting datasource
* Modified warnings to errors in logs
* Fixed test
* Fixed test
Upgrades vulnerable dependencies in all plugins except for MySQL. That one is still failing and I'll fix it in a separate PR. Issue #14475
Co-authored-by: Nayan <nayan@appsmith.com>
Co-authored-by: Anagh Hegde <anagh@appsmith.com>
* ArangoDB has two types of command - one that fetches a response and the other that updates a document. Currently, ArangoDB plugin treats all cmds like the one that returns a response, hence when update cmds are run then an empty response is returned to the client since there is nothing to fetch. This PR adds a check to fetch the response based on the type of cmd. Hence, for an update cmd the number of writes succeeded or failed would be returned as a response.
* Added field to autogenerate values in DB column
* Added comment and refactor
* Autogenerate field update according to names instead of type for ArangoDB
