You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Created by: Wes ([email protected]) on 2015/03/12 17:44:24 +0000
Votes at time of UserVoice import: 4
I think it would be prudent to return the Uid with all element queries and be able to search for an element by the Uid.
Imagine there is a custom element type called Invoices and a user is emailed a link to their invoice after purchasing a product. Each invoice link will need a unique identifier to be in the url. If the primary key is used as a route parameter to retrieve the element, this makes the public invoice identifiers sequential in nature, allowing a user to guess with relative ease what another invoice ID might be, possibly exposing sensitive information. If the invoice Uid was attached to the email link instead and the invoice retrieved by the Uid, it would make it much more difficult for another user to view the invoice.
This is just a simple example, and I realize there are measures that can be taken in the scenario above to alleviate this problem, such as requiring the user to login to view the invoice and then only showing the invoice if the current user's id matches the user's id associated with the invoice. However, what if someone wanted to do something like have guest checkouts and users are not required to create accounts? Sure, a custom field that auto-generated a Uid could be made, but a Uid already exists for that element, so why not use it?
This discussion was converted from issue #1047 on July 13, 2021 04:01.
Heading
Bold
Italic
Quote
Code
Link
Numbered list
Unordered list
Task list
Attach files
Mention
Reference
Menu
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
I think it would be prudent to return the Uid with all element queries and be able to search for an element by the Uid.
Imagine there is a custom element type called Invoices and a user is emailed a link to their invoice after purchasing a product. Each invoice link will need a unique identifier to be in the url. If the primary key is used as a route parameter to retrieve the element, this makes the public invoice identifiers sequential in nature, allowing a user to guess with relative ease what another invoice ID might be, possibly exposing sensitive information. If the invoice Uid was attached to the email link instead and the invoice retrieved by the Uid, it would make it much more difficult for another user to view the invoice.
This is just a simple example, and I realize there are measures that can be taken in the scenario above to alleviate this problem, such as requiring the user to login to view the invoice and then only showing the invoice if the current user's id matches the user's id associated with the invoice. However, what if someone wanted to do something like have guest checkouts and users are not required to create accounts? Sure, a custom field that auto-generated a Uid could be made, but a Uid already exists for that element, so why not use it?
Just food for thought.
Beta Was this translation helpful? Give feedback.
All reactions