Created by: Wes (wes@airtype.com) 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?
Just food for thought.
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.