I have Opened the connection, set the authorizations (Ex: PutIsReadOnly) and the hResult is 0. Then I did BeginSession and received a ticket and hResult of 0. But the authorizations don't seem to have taken effect. To make matters a little stranger, I then query the authorizations (Ex: GetIsReadOnly) and I get an hResult 0x8004040C (BeginSession has not been called or did not succeed). BUT the next thing the program does is query the customers and it returns records without a problem.
I don't understand how I can get an hResult that says BeginSession did not run or succeed when the program has a ticket and can get customers from QB.
The program is in WinDev and I would be happy to post code if someone thinks that would be helpful. Every other aspect of the program works fine except for authorizations. I figured that if I did not have the connection correct to IAuthPreferences2 that I would have gotten an exception or hResult <> 0.
Thanks
Related
I have a metaplex candy machine and collection that I set up several weeks back. Minting worked initially but is now failing.
The error reported is
custom program error: 0x3f
Which appears to be from the nested instruction to the metadata program. Which should be
set_and_verify_collection
readonly code: number = 0x3f;
readonly name: string = 'DataTypeMismatch';
It can be thrown from metdata deserialize.
https://github.com/metaplex-foundation/metaplex-program-library/blob/master/token-metadata/program/src/state/mod.rs
Which is called for the token metadata and collection metadata data.
I believe those are the only two places it would be thrown from in this method. AccountInfo is resolved for several accounts but it's only deserialized into a typed entity, with size and type considerations for those two entities.
Checking the metadata, on the collection, it's present and the length looks normal for metaplex metadata accounts at 679 bytes.
Now the metadata for the token being minted is not present because the tx failed. However, if, I attempt a transaction without the 'SetCollectionDuringMint' instruction added, the tx succeeds.
Interesting. The metadata account for the token has zero bytes allocated.
I don't recall this changing. In fact, if I go through my source history to older revisions, I've not been explicitly requesting to create the metadata account. I've simply been pre-allocating the account and calling mint nft on the candy machine.
Did the candy machine change to no longer automatically create the metadata account for the minted NFT?
It occurred to me almost as soon as I finished typing up the question, what the likely cause was.
It came to my attention a few weeks back that this older v2 version of the candy machine, does not actually halt transaction execution on constraint violations, but rather, charges the client a fee , for executing the transaction incorrectly.
It's likely the 'bot tax' protocol is allowing the real error, which may be occurring earlier, to get suppressed.
v3 of the candy machhine has made this something you can disable but we are a bit coupled to v2 at the moment.
Anyhow, what I think has happened here is that the bot taxing version of the candy machine, allowed the nft to mint, but didn't actually finish setting it up. Then the next instruction, set collection during mint, was unable to complete.
The real failure is earlier in the transaction, somewhere during the mint, where we no longer meet the mint criteria, and the old version of the candy machine is just charging us and failing silently.
Unfortunately, the root cause is still not clear. One other change that would have occurred between now and then is that the collection is now 'live' having passed the go live date. I'll have to dig through the validation constraints and see if there are any bot tax related short circuits related to this golive date transition.
EDIT: UPDATE: Looks like there were some changes, specific to devnet's token metadata program and my machine was affected. I'll need some new devnet machines.
In SlashDB, whenever a pass-through query can be executed, the HTTP code returned is always in the 200-class (OK, Created, etc.). Unfortunately, this doesn't account for cases when an error should be returned, such as: item doesn't exist in a table, etc.
Is it possible to force an error code from a pass-through query?
UPDATE:
I understand it is a an interminable debate whether a valid query should return an error code if it returns an empty set. There are valid arguments on both sides. I happen to think that if we think, say, a serial number is a resource and it doesn't exist, the call should return an error. Some details can then be placed in the response body as to how to further process the problem.
This question is not an attempt to seek answer to the aforementioned debate, but merely trying to discover whether there is a way in SlashDB to affect the HTTP error codes when using the SQL Pass-thru feature.
It's debatable if a query returning no rows is an error condition that would warrant a 404 Not Found. SlashDB behaved that way in earlier versions, but many developers complained.
Now, as long as the query is valid and executes without issues you will get a result and a 200 OK. It can be an empty list i.e. [], if there are no rows matching your query conditions.
Other error codes can be returned too. For example you will get a 403 if you don't have permissions.
Generally HTTP codes in the 4xx series indicate there's something wrong with a client's request. Codes in the 5xx series indicate some unexpected condition with the server i.e. database is down or time out from heavy traffic.
If this explanation does not address your particular query, please update your question with the query example and pertinent information about your database schema.
There doesn't seem to be a way to handle this in SlashDB. My solution to this is to declare an error on the MySQL side and a message_text to describe the problem. Because of this error, SlashDB returns an ambiguous 500 code.
It's a brute force solution, but it eliminates the ambiguity for now.
Orientdb throws on each live query subscripion using binary protocoll following Nullpointer exception:
Error executing live query subscriber. java.lang.NullPointerException at com.orientechnologies.orient.server.network.protocol.binary.OLiveCommandResultListener.onLiveResult(OLiveCommandResultListener.java:113)
at com.orientechnologies.orient.core.sql.OCommandExecutorSQLLiveSelect$2.call(OCommandExecutorSQLLiveSelect.java:134)
at com.orientechnologies.orient.core.sql.OCommandExecutorSQLLiveSelect.execInSeparateDatabase(OCommandExecutorSQLLiveSelect.java:144)
at com.orientechnologies.orient.core.sql.OCommandExecutorSQLLiveSelect.onLiveResult(OCommandExecutorSQLLiveSelect.java:131)
at com.orientechnologies.orient.core.query.live.OLiveQueryQueueThread.run(OLiveQueryQueueThread.java:69)
The Live Query is subscribed by one client: "live select from Account where CheckInDateTime like "2018-02-25%"", Orientdb returns also the live request token ID gracefully. But when another client updates Account with "update Account set CheckInDateTime = "2018-02-25 13:00:00"" the mentioned NullPointerexception is thrown. I've tried to use versions 2.2.30 and 2.2.32 Comunity, DB Administrator and Server Administrator accounts. Also loading of plugins seems not to work (even the used version is 2.2.30 and 2.2.32 where Live Query should be enabled at server by default). Nothing seems to help to get that work, also queries like "live select from account" (without where ...).
Any further ideas? Thx.
Currently live queries do not support the WHERE clause you included in the query.
You can only select entire collections or V and E (which is what I use to get all updates)
If you would like to filter using that where, you will have to write it yourself in code.
Thx for answering mitchken! Fortunately, I found the mistake. The TCP connection from client to DB was in wrong state (must be all the time in waitforreadyread).
I am practicing for Security Testing. I came across DVWA and I started practicing for Sql Injection. I was doing fine till I started with SQL Injection (blind). No matter which query I try I am not getting the desired result.
For eg :
1' and 1=0 union select null,table_name from information_schema.tables#
simply returns User ID exists in the database.
I have set the DVWA Security to Low. Also made sure there are no errors on setup page of the application under Setup Check section.
Following are environment details:
Operating system: Windows
Backend database: MySQL
PHP version: 5.6.16
I think the answer is here and the behavior is expected
https://github.com/ethicalhack3r/DVWA/issues/12
Someone complained of the opposite behavior and the developer agreed, and a contributor named g0tm1lk fixed it. He made the exercise really "blind" and we have to use blind injection methods to test the vulnerability.
Showing the SQL error messages to the user is just: a SQL injection vuln + a misconfiguration issue.
A blind SQL injection might occur when the columns of the results returned by a query are not shown to the user. However, the user can tell somehow if the query returned any records or none.
E.g.: Suppose the url "http://www.example.com/user?id=USER_ID" returns:
200 if USER_ID exists
404 if USER_ID not exists
But it won't show any information from the query results (e.g. username, address, phone, etc)
If the page is vulnerable to SQLi [blind], an attacker won't be able get info from the DB printed in the result page, but he might be able to infer it by asking yes/no questions.
I have this line of code within a request of an ApiController of an Azure Mobile App Web API:
var user = t.TrackDependency(() => context.Users.SingleOrDefault(x => x.Email == loginRequest.Id || x.Name == loginRequest.Id), "GetUser");
Here is the result from Application Insights:
We can see that while the line of code took 2613ms, the actual query call to the database took 190ms. While this is an edge case it happens often enough to get complaining users about slow performance.
The thing is I have no idea where the difference could come from. Note this is not due to a cold start, the app was warm when this exact call happened.
The second line is the actual call to the database endpoint. Before that it is not database related.
ps: the graph is from application insights. They capture the call to the database and I add my onwn data through the TrackDependency method.
UPDATE
Today I got more data thanks to Application Insights sampling (great tool!).
Here are the results (this is not the exact request call instance but this is the same problem):
It clearly shows that context.Database.CompatibleWithModel(false) is the culprit. It is called by the call to InitializeDatabase of my custom implementation of IDatabaseInitializer. My custom intializer is set at Startup.
I found another unanswered question on SOF with the same issue
Why does it take so long?
InitializeDatabase is not always called and I don't know when it is called and why.
I found another culprit:
Now we see that EntityConnection.Open is waiting something. Are there some locks on the connection? So far the call to the database endpoint is still not made so we're still on EntityFramework here.
UPDATE 2
There are two issues in that post:
Why is CompatibleWithModel slow? There are many articles about startup time improvements. This is not be adressed in that SOF question.
Why is EntityConnection.Open blocking. This is not related to EntityFramework but is general to getting a connection which takes up to 3 seconds if not called within a 5 minutes windows. I raised that problem in a specific post.
Hence there is no more questions in that post which and it could be deleted but may still be useful as an analysis of tracking down lost time in Web Api calls.