After watching the video about this subject, I understood that the INT being passed with the GET request of the "Find One" endpoint will always be:
- in the 4th segment
- the INT that will match against the mandatory "id" column of the table
Any changing of the "userOwnedSegment" params "column" and "segmentNum" did not allow me to match the 4th segment of the request url against any other column in the table.
I did have some odd results when changing the params:
This produced the expected results of only being able to query records matched to my trongate_user_id via the proper token.
This results in "invalid token" for every record attempted... as expected I assume.
Column "message_read" is a TINY_INT column I added to the table, putting a column that does not exist results in error.
This however resulted in me being able to retrieve ALL records by the ID being passed in segment 4, any "segmentNum" other than 4 let me have any record I asked for regardless of "trongate_user_id"
It gets even more weird, it seems that any other existing column I use, for example I added a "sender_user_id" column, and if I try this:
I get "invalid token" every time.
I am just an amateur and don't know if there is anything that could be exploited there, but I am wondering that "userOwnedSegment" authorization should just be "userOwnedRecord" with no additional params, because the "column" and "segmentNum" seem to be hard coded and mandatory that the column be "id" and the segment number be 4.
Is there something I am missing?
Authorization: userOwnedSegment
3 years ago
3 years ago
#1
3 years ago
#2
G'day Brian and welcome to Trongate!
I removed your second post as it was a double-up of sorts - and yes, we review posts because in the past we had people with malicious intent tying all sorts of rubbish.
I've pasted your second post as it had a follow-up of value:
I'm a little confused as was DC when he was trying to clarify this feature of the API - so I'm going to take a time out to review your question. If anyone else wants to try and solve this for Brian - please do.
I removed your second post as it was a double-up of sorts - and yes, we review posts because in the past we had people with malicious intent tying all sorts of rubbish.
I've pasted your second post as it had a follow-up of value:
I'm a little confused as was DC when he was trying to clarify this feature of the API - so I'm going to take a time out to review your question. If anyone else wants to try and solve this for Brian - please do.
3 years ago
#3
Thank you for the reply.
I am not sure I have a real question there but ran into this issue while trying to familiarize myself with the framework.
The idea I had was for a user requesting unread messages, which leads me to a real question.
I added the following to the api.json of my messages module:
and the endpoint in messages controller:
This results in retrieving messages that belong only to the user and have column 'message_read' < 1, 0 means not read, non-zero would be a read message.
This is not in a real project, just me playing around with ideas to learn the framework.
Would it be possible and useful if we were able to inject custom endpoints into Standard_endpoints, by adding into the api.json file as I did, and injecting the custom endpoint function into the Standard_endpoints so it could be called via /api/get_new_messages/messages?
It would maintain consistency across the app for api calls and prevent having to manually edit the Standard_endpoints.php which of course is a bad idea.
I am not sure I have a real question there but ran into this issue while trying to familiarize myself with the framework.
The idea I had was for a user requesting unread messages, which leads me to a real question.
I added the following to the api.json of my messages module:
and the endpoint in messages controller:
This results in retrieving messages that belong only to the user and have column 'message_read' < 1, 0 means not read, non-zero would be a read message.
This is not in a real project, just me playing around with ideas to learn the framework.
Would it be possible and useful if we were able to inject custom endpoints into Standard_endpoints, by adding into the api.json file as I did, and injecting the custom endpoint function into the Standard_endpoints so it could be called via /api/get_new_messages/messages?
It would maintain consistency across the app for api calls and prevent having to manually edit the Standard_endpoints.php which of course is a bad idea.
3 years ago
#4
Afternoon, (sorry this is going to be long) TLDR: Use custom routing to achieve what you want to do without modifying the Standared_endpoint.php
I am unsure as to what you are asking or not asking, but let me take a crack at this see if this clears anything up for you.
The userOwnedSegment authorization feature in Trongate is intended to enable API endpoints to fetch records based on a particular segment in the URL, which aligns with the primary key column (typically id) of the table. Its purpose is to ensure that only the records belonging to the authenticated user can be accessed.
the usage of the column and segmentNum parameters in the context of the userOwnedSegment authorization feature:
The column parameter serves the purpose of specifying the column name used for matching records. By default, it is set to id, indicating that the primary key column (id) will be used for record matching. It is not meant to be used with arbitrary columns from the table but rather for identifying the primary key.
On the other hand, the segmentNum parameter determines which segment of the URL should be utilized for record matching. By default, it is set to 4, implying that the fourth segment of the URL will be used for this purpose. This assumption is based on the typical URL structure of /api/controller/method/segment1/segment2/segment3/{id}.
When it comes to the usage of the userOwnedSegment authorization, it is important to note the following:
Regarding the column parameter: The userOwnedSegment authorization feature is specifically designed to work with the primary key column (id) and is not intended to be used with other columns such as message_read. Attempting to use it with a column other than the primary key can lead to unexpected errors, such as the "invalid token" error you encountered.
Regarding the segmentNum parameter: The segmentNum parameter is specifically designed to work with the default convention of using the fourth segment of the URL for record matching. Changing the segmentNum value to a different number can result in unexpected behavior, as the framework relies on the assumption that the primary key segment is located at the fourth position in the URL.
It is important to keep in mind that the userOwnedSegment authorization feature is primarily aimed at providing a straightforward and secure approach to enforcing record ownership based on the primary key column. If you require more complex authorization logic based on different columns or segments, it may be necessary to implement custom authorization checks within your endpoint's controller method.
So for example if you wanted to have a Parent Module of Dashboard, and a Sub Module of Messages(modules/dashboard/messages), but wanted to call the unread messages for the member on the dashboard you would do so like this.
Create your Dashboard module with this structure modules/Dashboard/assets/controllers/views
In the assets/ dir place a file called api.json
with this code added along with all your others such as "Get By Post" etc:
Then create your dashboard/controllers/Dashboard.php controller file with this code
Then create your modules/dashboard/views/index.php
Now start to work on the submodule Messages
Create modules/dashboard/messages/assets/api.json
just like before add this to the other code with your "GET" calls:
Create modules/dashboard/messages/Messages.php
I hope that clears things up! If you need more help please ask.
I am unsure as to what you are asking or not asking, but let me take a crack at this see if this clears anything up for you.
The userOwnedSegment authorization feature in Trongate is intended to enable API endpoints to fetch records based on a particular segment in the URL, which aligns with the primary key column (typically id) of the table. Its purpose is to ensure that only the records belonging to the authenticated user can be accessed.
the usage of the column and segmentNum parameters in the context of the userOwnedSegment authorization feature:
The column parameter serves the purpose of specifying the column name used for matching records. By default, it is set to id, indicating that the primary key column (id) will be used for record matching. It is not meant to be used with arbitrary columns from the table but rather for identifying the primary key.
On the other hand, the segmentNum parameter determines which segment of the URL should be utilized for record matching. By default, it is set to 4, implying that the fourth segment of the URL will be used for this purpose. This assumption is based on the typical URL structure of /api/controller/method/segment1/segment2/segment3/{id}.
When it comes to the usage of the userOwnedSegment authorization, it is important to note the following:
Regarding the column parameter: The userOwnedSegment authorization feature is specifically designed to work with the primary key column (id) and is not intended to be used with other columns such as message_read. Attempting to use it with a column other than the primary key can lead to unexpected errors, such as the "invalid token" error you encountered.
Regarding the segmentNum parameter: The segmentNum parameter is specifically designed to work with the default convention of using the fourth segment of the URL for record matching. Changing the segmentNum value to a different number can result in unexpected behavior, as the framework relies on the assumption that the primary key segment is located at the fourth position in the URL.
It is important to keep in mind that the userOwnedSegment authorization feature is primarily aimed at providing a straightforward and secure approach to enforcing record ownership based on the primary key column. If you require more complex authorization logic based on different columns or segments, it may be necessary to implement custom authorization checks within your endpoint's controller method.
So for example if you wanted to have a Parent Module of Dashboard, and a Sub Module of Messages(modules/dashboard/messages), but wanted to call the unread messages for the member on the dashboard you would do so like this.
Create your Dashboard module with this structure modules/Dashboard/assets/controllers/views
In the assets/ dir place a file called api.json
with this code added along with all your others such as "Get By Post" etc:
Then create your dashboard/controllers/Dashboard.php controller file with this code
Then create your modules/dashboard/views/index.php
Now start to work on the submodule Messages
Create modules/dashboard/messages/assets/api.json
just like before add this to the other code with your "GET" calls:
Create modules/dashboard/messages/Messages.php
I hope that clears things up! If you need more help please ask.
3 years ago
#5
Thank you for that!