I've got a question around best practices with the document id's in Watson Discovery. I've got a unique key in my data, and I'm wondering if I should pass that in as the id or let Discovery generate one. Any thoughts?
According to me, it is not possible to pass your own id (be its environment id, collection id, configuration id or document id) to Discovery service yet.
Every time, you create an environment or collection etc, Discovery itself generates a unique ID for it.
Note: Having manual intervention in generating IDs as well may lead to multiple confusions among the users as well.
Related
I just started working in openHAB and was wondering if there was an API to get the MAC-address of an item or some other unique ID that will not change if I for example disconnect/delete the device and reconnect it.
I want the unique ID so that I can put the Thing in a database without it creating a duplicate in case it disconnects or I delete the device.
I think the REST API is providing good information.
https://www.openhab.org/docs/configuration/restdocs.html
for example
openhaburl:8080/rest/things
You get a List of things containing, amongst other things, the UID and that contains the serial of the device.
Regards
Michael
Currently I am creating a RESTful API for a mobile application. The RESTful API has a number of end points that allow users to exchange personal information between each other. I was testing how secure these endpoints were and quickly realized that if a third party managed to gain access to the API they could easily look up other user's information by guessing their user id or using an automated script to collect a wide range of personal information. This was due to the fact that I was using a primary key that was a simple auto-incremented integer which made it predictable and easy to determine other user's ids. I immediately began looking for something that didn't follow a distinct pattern. I came across UUIDs and decided to implement them with my existing rails app.
Was this a wise decision? I definitely see the upside to using UUIDs but upon further research I found that there were a number of negatives to this approach. Many sources claim that using UUIDs will cause performance issues with large tables. Are UUIDs right for my situation?
My second question is about implementing this in an existing Ruby on Rails application. I made the switch to UUIDs by following this article: http://rny.io/rails/postgresql/2013/07/27/use-uuids-in-rails-4-with-postgresql.html. I ran into an issue with enabling the uuid-ossp extension. I created a migration and put enable_extension 'uuid-ossp' inside the change function. I then changed the existing migrations to support UUIDs as their primary key and ran rake db:drop db:create db:migrate to recreate the database with the edited migrations. This failed with the error PG::UndefinedFunction: ERROR: function uuid_generate_v4() does not exist. I quickly realized that this was because I had created the migration that enabled the uuid-ossp extension after the migrations that I had edited to use UUIDs. When I changed the time stamp in the name of the migration to a date that preceded all migrations the db:migrate command completed with no errors. This felt very hack and defeated the purpose of having migrations. What is the correct way of adding this extension via a migration?
Edit in response to comments:
So a number of comments were made that suggested that I should just be properly authenticating users and checking their permissions before allowing them to view certain data. I have user authentication built into my application but will better explain my situation and why I needed something more than auto-incremented primary keys.
I have a number of users on this application and each user has the ability to create private and public contacts. Public contacts are viewable by everyone using the mobile application. Private contacts can only be viewed by the user who created them. However, a user can share their private contacts with other users by showing other users with the mobile application a QR code that has the contacts ID encoded into it. When the user decodes the contact ID a request is sent to the backend to notify the backend that the user is now an owner of that private contact. This allows the second user to now receive updates from that private contact. This is a large feature of my application. The aim here is to force people to have to exchange these contacts in person and to disallow others from seeing these contacts unless this process has happened.
Implementing this concept proved to be fairly tricky as all users could potentially share all private contacts with any other user on the system. I found this extremely hard to implement using permissions as which contacts a user can view is constantly changing.
Originally I implemented this with auto-incremented integers as my primary key for the contact IDs. It worked but forced me to create a very insecure API endpoint that essentially would take a user ID and a private contact ID as parameters and would add that user as an owner of that contact. Because auto-incremented IDs are so predictable a user with access to the API could essentially loop through a sequence of numbers calling the endpoint each time, pass the sequence number in as the contact ID and add themselves as owners to contacts that hadn't been shared with them. This would by pass the whole process of having to share the contact in person and in large defeats the purpose of having my mobile application.
I decided I needed something less predictable, completely random and unique to each private contact. I found UUIDs while doing research to solve this problem and changed the contact ID in my model to be of type UUID. Are UUIDs the best way to solve this? Should I use something else? Have I gone about solving this problem the wrong way?
Are UUIDs the best way to solve this?
You could use them as a solution. If you do, you should build a new contacts table and model instead of trying to migrate the old model. As well as being tricky to implement, any migration would immediately make existing contact/invite emails invalid (since they contain the old id). Briefly support both models, and retire the old auto-incrementing id model once you are happy that traffic using it is no longer important to your application.
There is still a flaw - your contact share links will now be long-lasting, and if anyone gets access to a contact's id for any reason, and know enough to construct the URL for gaining that user as a contact, then they gain the ability to share it to themselves and anyone else completely outside of the control of your application. This because you are relying on knowledge of the id as the only thing preventing access to the contact details.
Should I use something else?
In my opinion, yes. Use a separate nonce or one-off code model (with UUIDs, or an indexed column containing a long random string - you could use SecureRandom for this) that can grant rights to complete the sharing. When someone wants to share a contact, create the nonce object with details about what is being shared - e.g. the contact_id - and use it to generate email link pointing to a route that will find the nonce and allow access to the resource.
The model doesn't need to be called "Nonce" or contain that as a column, this is just a common name for the pattern. Instead you might call the new model "ContactShare" and the secret property "link_code".
This will allow you to resolve access to contacts using your app's permissions model as normal, and block the possible misuse of sharing links. When the controller with the nonce id or code is invoked, create permissions at that point in order to grant access to the contacts. Then expire or delete the nonce, so it cannot be re-used. I prefer expiry, so you can track usage - this can be as simple as a used boolean column that you update once the sharing request has succeeded.
Note I am not referring to Rack::Auth::Digest nonce routine, which is specific to server authentication. I did not find a RoR pre-built nonce model, but it is possible it goes under a different name.
I have a rails app with gem 'braintree'.
Documentation:
https://developers.braintreepayments.com/ios+ruby/reference/request/credit-card/create
https://developers.braintreepayments.com/ios+ruby/reference/response/customer
I would like to change the way I store customer ids in the vault. (say, from "BT_#{id}" to "SOME_OTHER_KEY_BT#{id}")
I would like to keep the existing cards each customer have in the vault.
Two approaches:
Updating existing customer ids in the vault. The problem is that I don't find a way to just update (doc) the customer, because I cannot specify the parameter customer_id. This parameter is used for reference, not as a value you specify to update.
Re-creating all customers in the vault. The problem with that is that I would need to re-add every customer card info, and I don't have all the information needed (such as the card numbers) to re-submit the info.
Any suggestions ?
I work at Braintree. If you have more questions, please get in touch with our support team.
The general suggestion in cases like this, is that you really shouldn't care what the Braintree customer ID is; you should store it along with your own customer ID in your database so you can map between the two. For all other purposes other than communicating with Braintree, you should use your own ID.
I've read the documentation and samples multiple times and can't find out how to do this.,
I'm trying to wire up DB4O to use my own custom Id field. based on the documentation you can define your own IDs but as far as I can tell they won't replace Db4o's internal IDs, As in it won't actually use those Ids to identify the objects.
Basically all the examples do are tell Db4o to generate some sort of unique id and index it, I don't see anywhere on how to tell it that this is the ID that you should use.
Is it possible to have our own IDs on our model replace the internal IDs used to keep track of the relationships?
we need to have our own Ids since our system relies heavily on REST.
There no direct support for this. You need to create your own mechanism.
Simplest way: Use Guid on .NET. Or use a UUID in Java. In Java: Add UUID-Support: configuration.common().add(new UuidSupport());
Use callback to create new id's. Doesn't not work in TCP client/server.
See also this page.
Side note: You build a REST app. How many request does it need to handle? db4o is internally inherently single threaded. It can only handle a very limited load.
i have a order catalogue web site and i want to create a REST API so people can create their own apps and Add an Order or Update an existing order:
Lets say an order has:
OrderId
Product
Quantity
ShippingType
So i need some API to allow someone to send in a new order (orderid would be blank as that would be in the response).
How do you deal with passing in items like Product or Shipping type. These are tables in my db and are keyed off their own specific primary key id. Should the NewOrder API ask for a string name for these fields, should it ask for the id. If it asked for the ID, that would assume they would have to call the GiveMeProductList() method upfront (which gives you the name and id of all product as a dataset).
What is the standard for dealing with this?
Martin Fowler has a good post about the steps toward the glory of REST that you might find useful to come up with REST API.
The media type that I use for sending this information to the server can handle both scenarios, Id and Code/Name. If the user enters the product code manually then I send up the code, if the user asks to pick from a list then I provide the list and send back the Id.