Angular Login using password field

Baserow Help
1

I have a self-hosted environment with Rowbase and I have a user table with a password type field.
My idea is to create a login using the data from that table.

http://XX.XX.XX.XX:YYYY/api/database/rows/table/531/?user_field_names=true&filter__Correo_Electronico__equal=jevc@gmail.com&filter__Contrasenia__equal=123456789

When invoking the api and passing the username and password from the front, the api answers the following:

{
    "error": "ERROR_VIEW_FILTER_TYPE_UNSUPPORTED_FIELD",
    "detail": "The filter equal is not compatible with field type password."
}

I have looked for information on how to use the password type field but I have not found anything about it.

How can I use the filter using the password type field?

Thank you so much!

2

Hi,

The password field is only intended to be used with the Application Builder at the moment. It is not like a regular text field that can be used for filtering.

However, you can use the API endpoint user_source_token_auth: Baserow API spec. This allows you to pass a username and password and returns a token. If a token is returned, you know that the combination of the username and password is correct.

3

Thank you for the support and your prompt response. I check the option to generate and use the access token

4

Hi @frederikdc

What the returned token can be used for ?

Full base access ? Or only data sources of the respective baserow application ?

5

Hi @valexico, the refresh and access token returned by the email+password authentication endpoint gives access to everything in your account. It’s the same one that our web-frontend uses after you log in. It should not be exposed publicly.

6

Mmm this mean than if you build a baserow app, all users get access to your complete baserow account ? It does not sound very secure.

Is it a temporary situation ?

It also means that filtering data source in application builder is not a security measure ? I was actualy wondering ?

7

Not necessarily, it offers access to the tables where the authenticated user has access to. If you create an account that only has read access to a limited number of tables, you can only access those tables with the token.

There is a good article on our blog that explains the difference between the JWT tokens and database tokens

If you create a data source with a filter in the application builder, it will only return the number of records that match with the filter.

8

Hi @frederikdc

I need to come back here because it’s still not clear :slight_smile:

Regarding user_source_token_auth

  • It can be used to authenticate against a “user source”. That is if my understanding is correct a table with a password field and a login field, declared in an Baserow App ?
  • It will token an access token giving access to all the data accessible by the app owner ? (@bram response above)
  • So even if you declare a user-filtered data source in the app, under the hood it is possible to retrieve the un-filtered table ?

I am trying to figure out the level of security in a Baserow App with user-filtered data sources. By “user-filtered” datasource, I mean filtered using connected user’s user ID

9

Hi,

I just ran a test and you cannot use the token from the user source to gain API access to data this is not exposed though a data source. If I try to sign an API request that wants to return all records from a table, I get the following error.

So, the token is only used for getting access to data sources and executing workflow actions within the application builder. It offers no access to the underlying database.

error": 
{
"message": 
"401 - "{\"detail\":\"You are not allowed to use this user source to authenticate\",\"error\":\"user_source_not_allowed\"}"",

So, the token is only used for getting access to data sources and executing workflow actions within the application builder. It offers no access to the underlying database.

10

Hi @frederikdc

Thanks for your tests. I ran a few tests myself as well, but I am not a Baserow expert and I am still a bit confused :slight_smile:

I guess this conversation is maybe at the wrong place (it should be in app builder section) but I feel we really miss some guidelines regarding app builder security (which data is exposed or not).

  • I understood that setting visibility restriction in an application upon user being logged or not is not an actual security at the moment (you are quite clear about that)
  • All data-source endpoints are indeed publicly accessible (even if you link the application to a user source). But I am trying to understand how does it behave when there is data-source filtering based on logged in user id. Is that an acceptable security measure ?
  • which possible other endpoint could be exposed when publishing an application (I am wondering if a user credential on an application could expose as side effect some permissions on other application or even database table API, as the JWT is somehow related to the owner of the application if I understood)
11

@jrmi : can you answer the above concerns?

12

Sure @frederikdc

Current Behavior:

When you create and publish an application, only declared data sources are accessible through public endpoints. This means that only tables used within these data sources are exposed. Even if the application designer has access to more tables, only the specific tables declared as data sources will be accessible.

Data access is limited by the permissions of the user associated with the selected Baserow integration. You cannot declare a data source for a table that the application designer doesn’t have visibility over.

If you want the application to have fewer access rights, you can change the user associated with the integration. However, this step is not necessary for ensuring security of the published application.

When a data source has filters, only the filtered data is exposed. Data source filters are executed in the backend. If, for example, you filter a data source by the logged-in user’s ID, only that user’s rows will be visible to them. So yes, this filtering acts as a security measure.

The same principle applies to actions like create, update, or delete records. If no action is defined, no one can modify the exposed data sources. As soon as you define actions, they can be triggered via the API. If the action relies on internal data (e.g., logged-in user ID, data source properties, …), the user cannot manipulate these values. However, if the action depends on a page parameter, users may alter it. For example, if you define a delete action that uses a row ID from a filtered data source, only the filtered rows can be deleted. But if you rely on a page parameter for the row ID, any row could be deleted by the user.

However, currently, we cannot restrict data sources to a subset of users and all fields of a table are returned via the data source, even if they contain sensitive data. This is something we plan to improve.

Upcoming Improvements:

Soon, data sources and their fields will be filtered based on the current user and his role. If a record property is visible to the user, it will be included in the API response; if not, it won’t. If no properties are visible, the data source won’t be returned at all.

You are already able to configure element visibility based on user authentication status (logged-in or anonymous) and role. But soon, the system will automatically calculate which fields should be returned by the API based on what the user can see through the visible elements.

At that point, we will have full security, and the API will only return data visible to the authenticated user.

Is it clearer @valexico?

13

It is perfectly clear, thank you very much @jrmi

I want to add that I consider myself an experienced builder on a large set of solutions (Airtable, Bubble, Noodl) and I benchmarked a lot of tools in the last years (appsmith, noloco, stacker, retool…)

I find Baserow App builder very promising:

  • Database and App builder on the same platform is a great advantage
  • Open-source and self-hostable
  • App user distinguished from baserow account users
  • It already accepts custom code (embeded html) and it will also make a great difference
  • Nice support and community :slight_smile:

Of course at the moment some features are still missing but you are definitely going in the right direction :slight_smile:

Cheers