I'm experimenting with HTLC in Corda and ideally I'd like to encumber fungible tokens. The question then arises for me: when I want to unencumber a token, how do I "tell" the transaction builder which token I'm trying to unencumber, if they are fungible? Should I extend TokenType to add a unique identifier attribute? Then I'm curious - what happens to that identifier when the tokens are eventually split and recombined? Perhaps I'm going about this the wrong way; or perhaps I just shouldn't encumber fungible tokens.
Not sure what HTLC is.
To answer your question, you can make any corda State encumbered, or a token (or both, just extend/implement both). You just have to make sure to implement the correct interfaces.
When you use transactionbuilder you're just going to add the output state, so you don't have to tell transactionbuilder per se. You just want to make sure you construct the output state correctly and the transactionbuilder will use it.
I'm not sure what would would happen if you tried to split an encumbered fungible token, presumably you'd get an error? Ideally though you probably wouldn't need to run into this on an encumbered state anyway.
Try to figure out why your design needs both of these properties as it's certainly not something that happens often.
thanks and good luck
Related
I have been inspecting a variety of websites recently and keep encountering URLs containing strings like this, sometimes capitalised, sometimes not:
c8e700e6-4166-11e7-82b6-896b95f30f58
Does anyone know the significance or origin of this? Is it an encoding schema, something to do with the webapp framework, or something else?
Thanks
In technical terms, it's called a UUID or a universally unique identifier (aka GUID). The purpose is almost always to ensure that the page loaded by the browser is a unique URL and therefore not cached, but it can also be used to uniquely identify a session with the server.
It's not usually considered to be best practice to do it this way.
This is a GUID, use for better future unity.
Remove the possibilities of conflict on database of two companies.
PS:Sorry for my English.
I have a dilemma in my current project about my url. I would like opinions about how can I choice my route to access a resource.
For example, if a a USER can follow an other one, should I use /users/{user_1_id}/follow/{user_2_id} or /users/follow/{other_user} or /users/folllow with the id in parameters ?
I personally think that /users/follow/{other_user} think to be the best, but I don't know if it's the good choice.
Can I have your opinions ?
As for REST-Services you may consider having your services "state-less"... Therefore I would suggest to add all parameters needed for the service to process the request.
/users/{user_1_id}/follow/{user_2_id}
It gives you a.) better readability and better understanding of the service based on it's API (the URL) and b.) you will be thankful if you've to replace that service in the future (no headaches about where all the needed information is, no caching involved, less side-effects)... Other team-colleagues don't need to know more details about the service ("is the user cached in the background", "or is there a hidden user-id in the cookie", etc.)
Guys i'have a question.
I'm currently buiding a wizard that has 5 step's until being completed.
The user starts by the first step where he generates the entry id.
From there on i start passing the id over the url like this:
host.com/{controller}/{view}/{id}
This is how my url looks like after the step1,
------- currently at view step2 passing the id=120
host.com/{controller}/step2/120
This isn't safe because as you know, anyone can change the id and affect other users's entries. Ofc, it can be quickly solved by reading if the authenticated user is proprietary of the entry that he must be trying to access in each view.
Now, my question is... is there a better way to do this?
Any tips for future work?
Is what i'm doing enougth?
(begginer doubt praying for a expert awnser)
Cheers
...It can be quickly solved by reading if the authenticated user is proprietary of the entry that he must be trying to access in each view.
Yes, that's true. You should start there.
Here are some other things that you could do:
You could make your entry ids Guids instead, so that a would-be hacker would never try to guess an entry id.
Because using GET for sensitive data is a bad idea, you could, as endyourif suggests, pass the entry ids with hidden fields instead.
If you are truly concerned about the user altering the ID in the URL, then you must spend the additional time adding an "isOwnedBy" like functionality.
As an additional security measure, you could pass it via a hidden variable in the form so it is at least not as easy to change as well.
Edit: I like #LeffeBrune's suggestion of encrypting the idea as well. However, I still suggest that the validation is performed on the function to ensure the user owns the object. It's just good practice.
What exactly does SignedCookieJar do?
And what is the difference from that and using MessageEncryptor.encrypt_and_sign on the cookie value?
If you're ever looking for exactly what a given class does, I'd recommend consulting the source. SignedCookieJar, for instance, is in rails/actionpack/lib/action_dispatch/middleware/cookies.rb.
It would seem that a SignedCookieJar is a wrapper around the standard cookie jar, but before setting a cookie to its parent jar it will sign it with an ActiveSupport::MessageVerifier's generate method, and upon getting a cookie from the parent jar it will return nil if the verifier's verify method invalidates the signature.
The difference seems to be that MessageVerifier only signs data but leaves the original data intact, whereas MessageEncryptor will additionally encrypt the data before signing it. The Rails docs say that the use case is different in that:
[MessageEncryptor] can be used in situations similar to the MessageVerifier, but where you don’t want users to be able to determine the value of the payload.
For signed cookies, we're usually not too worried about that.
For one of my project's (weird) requirements, I want to use cookie less sessions. At the same time, "session.use_trans_sid" can not be turned on :(
Does anybody please let me know if is there any other way out ??
Thanks
Manish
Make a custom session manager that identifies the user based on, for example, IP address and user agent and other identifying factors (as IP+UA might not and probably will not be unique). Another (ugly) solution is to just implement the use_trans_sid functionality yourself by adding a session identifier GET parameter to every link by hand (if it's a small site) or with a hidden form (that's non-standard).
If you really want sessions without cookies, you can always put the SID in all your URLs manually. People used to do this quite a bit. :-)
The only other option is to keep the session data on the client and pass it back and forth to and from the server with each request, although technically that would be a sessionless architecture.
That means that for GETs each link has to be rewritten to include all the session variables, and for POSTs they have to be included as hidden fields.