How are buckets isolated on Forge autodesk? - autodesk-forge

Description of observations:
Between several apps I own, if I create a bucket in one, I am not allowed in the other. I assume I could but no (exemple, an app for dev/staged/prod with same bucket name), I have "reason": "Bucket already exists".
When I create a new app and try to create some buckets, with some common names (azerty/qwerty/demo/test/...), it is not possible, because it tells me "reason": "Bucket already exists" This makes me wonder if another app can grab some buckets name I then cannot use. (note: when I use random names like uuid or like, I never have conflict)
How are buckets isolated on Forge autodesk?
How should I consider to use bucket name?
(since current observation makes me think buckets are not so isolated between apps...)
Thank you,

you are correct on the understanding on bucket name. From the API help, the requirement is
A unique name you assign to a bucket. It must be globally unique across
all applications and regions, otherwise the call will fail. Possible
values: -_.a-z0-9 (between 3-128 characters in length). Note that you
cannot change a bucket key.
i.e. it is global unique. Currently, I do not see a way to check if it is unique before creating a new bucket, while normally if such format would be working: < your company name >.< your app name >.< your bucket name in this app >, While since Forge has not something like Java group id registration, such name might probably be also conflict if other customer happened to create by such name, but much lower possibility.
another of my practice is: < your app client id >.< your bucket name in this app >. Since client id is unique, this will ensure the final bucket name is unique. It would also be helpful to find which app this bucket belongs to.
generic guid is fine, while you would have to manage a map on what the bucket is for.

Related

Securing MySQL id numbers so they are not sequential

I am working on a little package using PHP and MySQL to handle entries for events. After completing an entry form the user will see all his details on a page called something like website.com/entrycomplete.php?entry_id=15 where the entry_id is a sequential number. Obviously it will be laughably easy for a nosey person to change the entry_id number and look at other people's entries.
Is there a simple way of camouflaging the entry_id? Obviously I'm not looking to secure the Bank of England so something simple and easy will do the job. I thought of using MD5 but that produces quite a long string so perhaps there is something better.
Security through obscurity is no security at all.
Even if the id's are random, that doesn't prevent a user from requesting a few thousand random id's until they find one that matches an entry that exists in your database.
Instead, you need to secure the access privileges of users, and disallow them from viewing data they shouldn't be allowed to view.
Then it won't matter if the id's are sequential.
If the users do have some form of authentication/login, use that to determine if they are allowed to see a particular entry id.
If not, instead of using a url parameter for the id, store it in and read it from a cookie. And be aware that this is still not secure. An additional step you could take (short of requiring user authentication) is to cryptographically sign the cookie.
A better way to implement this is to show only the records that belong to that user. Say the id is the unique identifier for each user. Now store both entry_id and id in your table (say table name is entries).
Now when the user requests for record, add another condition in the mysql query like this
select * from entries where entry_id=5 and id=30;
So if entry_id 5 does not belong to this user, it will not have any result at all.
Coming towards restricting the user to not change his own id, you can implement jwt tokens. You can give a token on login and add it to every call. You can then decrypt the token in the back end and get the user's actual id out of it.

Model Derivative API: What is the scope of a bucket?

Can you please give a bit more information about the scope of a bucket? I experienced a situation that I started with searching for a bucket, and I did not find it into my actual list of bucket keys.
Ok, but trying to create a new bucket with that key, I received the error that this was not possible because it was already a bucket with that key. {"reason":"Bucket already exists"}
The bucket name is globally unique, so there is a chance that the bucket name you specified is actually used by some other app, so we usually would suggest you to make the bucket name something like "companyname-appname-bucketname" to avoid conflict, please check the following note in https://forge.autodesk.com/en/docs/data/v2/reference/http/buckets-POST/:
**bucketKey**: A unique name you assign to a bucket. It must be globally unique across all applications and
regions, otherwise the call will fail. Possible values: -_.a-z0-9 (between 3-128 characters in
length). Note that you cannot change a bucket key.

google-places-apiI had a place id in my database which returns 0 result

I had in my database the followings places id :
ChIJ4X4hzjm7rhIRVigYuqinSe4
ChIJmyWoeEEM5kcR_8LHmraJvOs
ChIJdXD8rrkM5kcRdynfSAYhm8E
But when i use the google service geocoding :
https://developers.google.com/maps/documentation/javascript/examples/geocoding-place-id?hl=fr
I am sure it was a valid place id.
I have no result, do you have a idea ?
It is really difficult to address this question on StackOverflow, because you need access to internal Google database in order to investigate what happened with these place IDs.
I can see a couple of possible scenarios when this might happen that place ID stop working:
The place ID was marked as duplicate of another place ID, so it was merged with another feature and doesn't exist anymore
The place ID was flagged by users on maps.google.com or mobile app as wrong and was removed by Google team from the database (https://support.google.com/maps/answer/7084895).
In order to avoid these issues I would suggest storing place IDs along with an original query in your database. In this case if place ID that previously worked returns ZERO_RESULTS or NOT_FOUND you can rerun the original query and get an updated place ID.

Storing userID and other data and using it to query database

I am developing an app with PhoneGap and have been storing the user id and user level in local storage, for example:
window.localStorage["userid"] = "20";
This populates once the user has logged in to the app. This is then used in ajax requests to pull in their information and things related to their account (some of it quite private). The app is also been used in web browser as I am using the exact same code for the web. Is there a way this can be manipulated? For example user changes the value of it in order to get info back that isnt theirs?
If, for example another app in their browser stores the same key "userid" it will overwrite and then they will get someone elses data back in my app.
How can this be prevented?
Before go further attack vectors, storing these kind of sensitive data on client side is not good idea. Use token instead of that because every single data that stored in client side can be spoofed by attackers.
Your considers are right. Possible attack vector could be related to Insecure Direct Object Reference. Let me show one example.
You are storing userID client side which means you can not trust that data anymore.
window.localStorage["userid"] = "20";
Hackers can change that value to anything they want. Probably they will changed it to less value than 20. Because most common use cases shows that 20 is coming from column that configured as auto increment. Which means there should be valid user who have userid is 19, or 18 or less.
Let me assume that your application has a module for getting products by userid. Therefore backend query should be similar like following one.
SELECT * FROM products FROM owner_id = 20
When hackers changed that values to something else. They will managed to get data that belongs to someone else. Also they could have chance to remove/update data that belongs to someone else agains.
Possible malicious attack vectors are really depends on your application and features. As I said before you need to figure this out and do not expose sensitive data like userID.
Using token instead of userID is going solved that possible break attemps. Only things you need to do is create one more columns and named as "token" and use it instead of userid. ( Don't forget to generate long and unpredictable token values )
SELECT * FROM products FROM owner_id = iZB87RVLeWhNYNv7RV213LeWxuwiX7RVLeW12

How to get the latest document in couchbase bucket?

I have a activity bucket in my couchbase-db and I need to retrieve the latest document for different types, My initial approach was this:
Document Format : [ id , { val.time ,val.type, val.load } ]
And then I wrote different views to Map a specific val.type and I used reduce to get the latest val.time, However I have the problem of views not being updated ( Cause apparently the Map is only called on new or changed documents and this approach needs all of the documents to be mapped and reduced.)
What is the best practice / approach for time-based data on Couchbase ( NoSQL ) databases ?
You can access the documents by time with a simple view like this:
Convert your time to an integer value. Eg using the parse() method. http://www.quackit.com/javascript/javascript_date_and_time_functions.cfm
Use this integer value as the key to your view. You can then access the first or last document.
If you always need the last document it's faster to negate the time value, so the largest times are at the start of the index.
If you are using a development design document, it is expected that adding new keys into your bucket may have no effect on the view. Since only a subset of keys from the bucket are going into the Map/Reduce pipeline, adding a key that is not going into the subset would trigger no update to your view.
Either evaluate it on a production design document (by clicking the "publish" button), or try adding more keys.