Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 2 years ago.
Improve this question
I am continuously fetching the data and initiating new contracts and updating the templates if data is modified. I am getting the following error, which I am unable to figure out when it is occurring while updating or some other reasons.
Error: 3 INVALID_ARGUMENT: Inconsistent: Causal monotonicity violated
at Object.callErrorFromStatus (/home/prachi/Documents/waste-water-management/trip_daml/contractService/node_modules/#grpc/grpc-js/build/src/call.js:31:26)
at Object.onReceiveStatus (/home/prachi/Documents/waste-water-management/trip_daml/contractService/node_modules/#grpc/grpc-js/build/src/client.js:176:52)
at Object.onReceiveStatus (/home/prachi/Documents/waste-water-management/trip_daml/contractService/node_modules/#grpc/grpc-js/build/src/client-interceptors.js:342:141)
at Object.onReceiveStatus (/home/prachi/Documents/waste-water-management/trip_daml/contractService/node_modules/#grpc/grpc-js/build/src/client-interceptors.js:305:181)
at /home/prachi/Documents/waste-water-management/trip_daml/contractService/node_modules/#grpc/grpc-js/build/src/call-stream.js:124:78
at processTicksAndRejections (internal/process/task_queues.js:79:11) {
code: 3,
details: 'Inconsistent: Causal monotonicity violated',
metadata: Metadata {
internalRepr: Map { 'content-type' => [Array] },
options: {}
}
}
Causal Monotonicity ensures that Ledger Time follows causality. For example, it should not be possible that a fetch on a contract happens before its create in Ledger Time. The precise rule is explained here.
In earlier versions of DAML, the client application had to supply the Ledger Time via an API field called ledger_effective_time or some such. That time had to be set in such a way that the Ledger Time of the transaction was equal or later than the Ledger Time on any input contracts to that transaction. That's really quite difficult in practice because input contracts can be pulled in via ContractIds and Contract Keys.
For that reason, the model was changed in SDK 1.0 in such a way that a suitable Ledger Time is determined by the node to which the command is submitted. It's not only possible to give minimum bounds using the min_ledger_time_abs and min_ledger_time_rel parameters.
So, is you are on SDK < 1.0, you are running into a known difficulty with the old Ledger Time model. You'll either need to set ledger_effective_time very carefully, or upgrade to SDK >= 1.0.
If you are already on SDK >= 1.0, you have likely run into a bug, which you should report to the developers.
Related
I'm writing a basic fantasy sports smart contract as a way of learning Solidity. The api really only exposes one function to non-admins and it's the "create entry" method. The user submits six teams and the contract validates whether they exist and if they're within cost and then creates an entry. So, there's a decent amount going on.
I'm testing the function and I'm getting an out of gas exception. So, my question is: how do I assess how close I am to getting within gas limit and how do I approach getting it there?
you could use the web3.eth.estimateGas() function, assuming you're using web3 api.
The question in the link below asks a question relating to the function I mention.
What are the limitations to estimateGas and when would its estimate be considerably wrong?
This question already has an answer here:
GETCHALLENGE issue(6D00) in EMV for MasterCard
(1 answer)
Closed 5 years ago.
In the case of GETCHALLENGE Request (0084000000), we are getting the positive response in the case of VISA\DEBIT card, but for AMEX and MASTERCARD we are getting the response as 6D00 (Instruction code not supported or invalid).
Not all instructions are supported by all card products. Different card products also support different transaction types, off the top of my head (so take my answer with a grain of salt) get challenge should online be necessary for offline transactions with asymmetric crypto where the terminal needs to identify itself to the card. It's possible (though not likely nowadays) that the card doesn't have a crypto coprocessor capable of handling this, so that code path is disabled. It's also possible that the MC and Amex EMV scheme specifics require a different transaction flow and you're not fulfilling the prerequisites for get challenge.
Without konw the sequence of commands you're sending to the card and the profile on the card, it's difficult to provide more information than the 6D00 is already providing.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Tasked to detail a simple API, I did a little research and suspect everything I know about the Internet is wrong.
I've Googled for far longer than I care to admit, reading a number of articles, StackOverflow questions and websites that all seem to vehemently disagree. I recognize every developer does things differently, but still suspect there is an official standard somewhere, or at least a general best practice (although, admittedly, not everyone follows whatever the best practice).
This API would use JSON. That I cannot change.
What my local peers do/have told me (very likely incorrect):
HTTP is a complex, antiquated beast that we should deal with as little as possible. It's simply a vehicle for moving chunks of JSON back and forth, where the magic happens. All data and metadata should be in the JSON, and you can set it up exactly as you like.
Use a 200 status code for everything, even if there is an application-level error or problem with the user's input. The other error codes mean something went wrong with the HTTP operation--a catastrophic unexpected server error, using the wrong URL, that kind of thing.
"Envelope" the JSON data for messages from the server; have JSON properties for metadata and include the actual JSON object/array inside a consistent property, like "data"
HTTPS is "nice to have" but not important for minor projects
Use PUT requests for everything
Log in to get a randomized strong of characters as an access token from the server. The server stores information on when the token expires, what account it is for and what IP address used it. Pass that access token to the server for every other call; the client does not store the password.
URLs tend to be verbs, like /register or /checkout or /changepassword. All other needed data is in the JSON. Each operation has its own URL
What I THINK might be right based on my reading, but not sure
HTTP is the divine data structure. Header information and server return codes can encompass any possible metadata and is, indeed, designed for that purpose. The contents need only contain the actual JSON object(s) the applications are acting upon. Put nothing in the JSON body that could possibly be part of the HTTP metadata.
ALWAYS use HTTPS, for everything
For any possible error (a form field didn't validate, the user's session expired, their game character is dead), send an HTTP status code. Try to pick what seems closest based on the W3C descriptions, but all that really matters is that you use it consistently in your system. The code should be enough to tell the client app what to do (show user validation errors and make them fix form input, make user log in again, take user back to main screen). The body, in case of errors, contains extra details about the error, if necessary.
The client app should pass login info with every request, in the HTTP header. This means it needs to use basic auth, which means it needs to remember the user's password.
The JSON data should never be in an "envelope". There is no standard format, because the contents directly represent the object(s) needed for the given operation as indicated by the combination of URL, GET/POST/PUT/DELETE
URLs tend to be nouns, like /user or /shoppingcart. Subdirectories of the URL refer to the object ID being acted on: /user/johndoe or /shoppingcart/12359. A URL could be used for different operations for GET (retrieve data) POST (update data) PUT (create new data) DELETE (remove data).
I'm not even sure that either of these is fully right--can you tell me the rules for what is the official, or most recommended way to structure such an API?
You should read the relevant part of the Fielding dissertation, that defines what REST is: http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
Some additional dissertation from Markus: http://www.markus-lanthaler.com/research/third-generation-web-apis-bridging-the-gap-between-rest-and-linked-data.pdf He started the work about creating a standard REST implementation: the http://www.hydra-cg.com/ RDF REST vocab and the http://json-ld.org/ RDF JSON format. Currently we don't have a standard solution to describe the uniform interface of any REST service. This is like if we would not have a HTML standard. That's why we are not able to write REST browsers just application specific clients.
(Hydra is not production ready, I guess they'll need another 2-3 years to standardize it and start to build Hydra specific tools. Until then we cannot really talk about real REST, because most of the APIs define an implementation specific format or use a non-standard more or less common format, like HAL.)
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 1 year ago.
Improve this question
I have read all the existing discussions on piracy and hardware support, so this is not the same old question. I have a new twist on this old discussion. You can now purchase dongles for USB that allow you to put some of your important code into the dongle. If you have a complex algorithm and you put it into the dongle, someone would have to reverse engineer the contents of the dongle. If they tried to spoof the dongle, as was possible in the past, this would not work. All they can see is that data goes into a "black box" and result data comes out. It is no longer a matter of finding a jump true/false to bypass a license check in the source code.
Perhaps a mathematician with a lot of idle time on his hands could eventually reverse it, but that is an extreme level of interest! The other option is that the hardware dongle itself would need to be hacked. There are many protections against this built in, but this is probably the most effective approach.
So I want to take a scenario and see if I've missed something. I put the important part of my algorithm into the dongle to protect it. 6 doubles and 1 int go into the dongle, 1 double and 1 int are returned. This happens for thousands of data points. This is one of several functions of similar complexity. A hacker can see the rest of my assembly code (which I do as much as possible to obfuscate), but lets assume it is easily hacked. My question is, how hard is it to break into the dongle to access my assembly code in this proprietary hardware? Let's take as an example this companies product: http://www.senselock.com
I am not interested in lectures on how I'm inconveniencing customers and should open source my product, please. I am looking for a technical discussion on how a software/hardware engineer might approach extracting my assembly object from such a device. And I am not asking in order to hack one, but to know how much hassle I have as my discouragement against tampering. I know if there is a will, there is always a way. But at first glance it looks like it would take several thousand dollars worth of effort to bypass this scheme?
Given the response so far, I am adding some more specifics. The dongle has the following property, "Access to the chip is protected by PIN, and the maximum re-tries is pre-set by software developers. For instance, under a dictionary attack, once the number of re-tries exceed the pre-set value, the chip will trigger a self-locking mechanism". So to access the chip and thus the code inside it, you have to know the PIN, otherwise after let's say 10 tries you will be locked out. I personally can't see any way anyone could compromise this system. It doesn't matter what goes in or out, what matters is what runs inside the dongle ARM processor. Physical forced access would destroy the chip. Electrical access would require the PIN, or the chip locks up. How else could it be compromised?
I pretty much agree with your point of view that all dongles could be hacked, it just the matter of time and cost. If your encryption scheme is well-designed the EAL 5+ chip should be secure enough to prevent your software form malicious attacks.
And I think if you can READ the dongle it's probably means you already hacked the dongle, or it proofs there is a fatal vulnerability in the encryption scheme.
BTW, the link you give above is not work. Are you referring to this dongle? http://www.senselock.com/en/productinfor.php?nid=180&id=142&pid=
there are companies(such as break-ic.com) which have the list of mcu which they can break.
after breaking they give you only hex files.
in this case(mcu)every manufacturer has its own disassembler because of hardware architecture of every mcu core and there is no guarantee that your desire disassembler is exist!!!
so you must search for dongles which they have unbreakable mcu or their mcu has no disassembler.
or you can build you own dongle!!
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I want to ask about the difference between bug and failure and error, i read that the error is mistake made by people, but i conflicted between the difference between the bug and failure. I can't know the difference exactly. Can any one help please and give simple snippet for code represents the difference.
Thanks a lot.
Bug is a programming error - not checking array bounds, ignoring error codes, multiple deletions, memory leaks, etc. fall under this general category. Errors like this require code changes to fix (there may be work-arounds that do not require code changes, though)
Failure is a system error - disconnection of storage, lack of network connectivity, and hardware failures are in this category. Fixing failures usually requires configuring other parts of the system, not the program itself.
User errors are mistakes made by users - entering values incorrectly or providing incomplete data are in this category. Errors like that are fixed by the user who uses the program without anyone else's involvement.
By my definition I would say
An error is about my behavior, or my acting. so I make errors.
A bug is the the result of my error in the program code.
The failure is the malfunction of my buggy software.
but others may interpret this differently.
A fault or Bug is a defect within the system (Somewhere hidden in the code and maybe never detected!).
An error is a deviation of the required operation of the system or subsystem. (The fault detected during execution but no harm).
A failure occurs when the system fails to perform its required function. (System crash)
An Error is a manifestation of a fault in a system, which could lead to system failure.
(Singhal/Shivaratri)
Example:
If you multiply x with 4 instead of 2 in your code, but there is no way to affect any functionalists or is not visible. This is a bug or fault.
If user can see it, let's say with having a wrong text as subject of email, then this is an error but still system worked and no harmful event happened.
But if your system withdraw the wrong money to user in a bank or your robot cut the head of the lady instead of cutting the cake for her then this is a failure :)
Instead of code snippets, I gave your examples below. I hope examples help you to understand the term better.
Bug is a term used among testers to address faults in software.
Error is a value or state or operation that is varies from expected value or state or operation. For example, programmer makes a mistake like missing a semi-colon, calling a wrong function name.
Result from system != Expected Result from system
Fault is a error brought into a system during design or implementation stage that is capable of causing system failure. Imagine some company X gives discount to their loyal customer. Loyal customer is someone who shops 10 times in a month. In software, programmer enter 20 times instead of 10. This is a mistake introduced by programmer called error. then it turned to fault. In tester language, it is a bug.
System failure is an inability of a system to do, what is required of the system. For example, if a user tries to sign up for account in a social networking site if they site fails to register the user. Then, that is system failure.
Technically,
Error -----> Fault -----> Failure
The root cause of any failure is error.