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.
Related
I am trying to achieve the same as these guys did: https://uniswap.org/blog/ipfs-uniswap-interface/
So first I read this:
https://docs.ipfs.io/concepts/ipns/
It says:
IPNS is not the only way to create mutable addresses on IPFS. You can
also use DNSLink, ...
So I went to read https://dnslink.io/, and then added a TXT _dnslink dnslink=/ipfs/<CID> entry to my DNS records.
Works perfectly.
But what about an update to content - won't the CID change? Do I have to update the TXT record every time the content changes? Is there a way to have the dnslink record point to always the last release?
https://uniswap.org/blog/ipfs-uniswap-interface/ says:
That TXT record contains the IPFS hash of the latest release.
So it suggest that it needs to be updated all the time. Maybe there is a programmatic way to update the TXT record so they don't have to go in all the time and change the hash?
Sligthly confused ¯_(ツ)_/¯
You can either:
Update the /ipfs/ CID in the TXT every time, programmatically or otherwise. Or, use an /ipns/ CID. With IPNS, you never need to update the TXT, but you need at least 1 IPFS node with the IPNS key to be online most of the time to regularly publish the IPNS record. If you do use IPNS, I recommend generating a new key for the content, not using the default node keypair. This makes it easier to move / copy the key.
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.
I want to configure Orion and Cygnus to store all data in a single table.
I know that I should configure the names of databe and table based in HTTP headers like so:
dbName=<fiware-service-header>
tableName=<fiware-servicePath-header>_<entityId>_<entityType>
I was told in this post to ask another question.
Cygnus uses the notified fiware-service and fiware-servicePath headers to compose the names of the different backend elements. Specifically:
MySQL
databases are called as <fiware-service>
table names are called as <fiware-servicePath>_<destination>
HDFS
HDFS paths are created as /user/<your_user>/<fiware-service>/<fiware-servicePath>/<destination>/<destination>.txt
CKAN
organizations are called as <fiware-service>
packages/datasets are called as <fiware-servicePath>
resources are called as <destination>
By default, <destination> is equals to <entityId>_<entityType>. This may lead, as described in the question, to the creation of a MySQL table/HDFS folder/CKAN resource per each notified entity.
Such a default destination generation may be changed by using an advanced feature of Cygnus, the pattern-based grouping; as the name suggests, the feature is based on finding (configured) patterns in the data, in order to group the context data showing the pattern. This feature allows, for instance, all the entities of a certain type are stored within a single MySQL table; or certain entities starting by a prefix are stored together in a HDFS file.
In order to activate this feature, edit the /usr/cygnus/conf/matching_table.conf file and add as many matching rules as you need; matching rules syntax is described here. Basically, the rules say "once the pattern-based matching is confirmed, use this new <destination> and this new <fiware-servicePath>":
<rule_id>|<list_of_fields_to_be_compared>|<regular_expresion>|<new_destination>|<new_fiware-servicePath>
Thus, a "store all the data in a MySQL table called 'my_unique_table'" rule would look like:
<any_unique_number>|<entityId>|.*|unique_table|my_
or:
<any_unique_number>|<entityId>|.*|_table|my_unique
Both rules are valid since MySQL table names are created, as already said, by concatenating <fiware-servicePath> and <destination>; in this case table name is equals to "my_"+_+"unique_table" or "my_unique"+"_table".
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
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.