https://docs.ipfs.io/guides/concepts/dnslink/
I think ipns uses a hash of your public peer id or something to create unique namespaces. I see no comment about how this works for DNSLink. What are the subspaces for DNSLink? If there is a global namespace as the documents suggest, how is this handled?
If I understand your question correctly, you ask how we handle DNSLink and IPNS on the same namespace when resolving /ipns/{value}.
In go-ipfs 0.4.23 we check if value is a valid Peer ID (see spec), if not, check if value is a FQDN with a DNSLink record.
Related
Chisel throws an exception with an elaboration error message. The following is a result of my code as an example.
chisel3.core.Binding$ExpectedHardwareException: data to be connected 'chisel3.core.Bool#81' must be hardware, not a bare Chisel type. Perhaps you forgot to wrap it in Wire(_) or IO(_)?
This exception message is interesting because 81 behind chisel3.core.Bool# looks like ID, not hashcode.
Indeed, Data type extends HasId trait which has _id field, and
_id field seems to generate a unique ID for each components.
I've thought Data type overrides toString to make string that has type#ID, but it does not override. That is why $node in below code should not be able to use ID.
throw Binding.ExpectedHardwareException(s"$prefix'$node' must be hardware, " +
"not a bare Chisel type. Perhaps you forgot to wrap it in Wire(_) or IO(_)?")
Instead of toString, toNamed method exists in Data. However, this method seems to be called to generate a firrtl code, not to convert component into string.
Why can Data type show its ID?
If it is not ID, but exactly hashcode, this question is from my misunderstanding.
I think you should take a look at Chisel PR #985. It changes the way that Data's toString method is implemented. I'm not sure if it answers your question directly but it's possible this will make the meaning and location of the error clearer. If not you should comment on it.
Scala classes come with a default toString method that is of the form className#hashCode.
As you noted, the chisel3.core.Bool#81 sure looks like it's using the _id rather than the hashCode. That's because in the most recently published version of Chisel (3.1.6), the hashcode was the id! You can see this if you inspect the source files at the tag for that version: https://github.com/freechipsproject/chisel3/blob/dc4200f8b622e637ec170dc0728c7887a7dbc566/chiselFrontend/src/main/scala/chisel3/internal/Builder.scala#L81
This is no longer the case on master which probably the source of any confusion! As Chick noted, we have just changed the .toString method to be more informative than the default; expect more informative representations in 3.2.0!
How does the STR-Transform transformation algorithm works for XML Signature, when working with WS Security? I need to sign the SecurityTokenReference used for the signature on a SOAP message, and this is the required transformation for the security token. I am using an x509 certificate to do the signature, so the security token is this certificate. However, in the message I only need the reference to the certificate thumbprint.
Here is the signature structure that I need to replicate, and the only bit that I am missing is the signature reference to the SecurityTokenReference:
<dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
<dsig:SignedInfo>
<dsig:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<dsig:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<dsig:Reference URI="#Timestamp_C1Ih1AB1vpPT5uG2">
<dsig:Transforms>
<dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</dsig:Transforms>
<dsig:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<dsig:DigestValue>fVSyToUO8yS131cV8oT1h6fa69Jvtt+pKFeP4BFf1P4=</dsig:DigestValue>
</dsig:Reference>
<!-- Other signature references -->
<dsig:Reference URI="#str_U1sjQ5j8JtKnObLk">
<dsig:Transforms>
<dsig:Transform Algorithm="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#STR-Transform">
<wsse:TransformationParameters>
<dsig:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</wsse:TransformationParameters>
</dsig:Transform>
</dsig:Transforms>
<dsig:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<dsig:DigestValue>gRa3zakGn13XISoKpekB3zl0iDqb/LmNy7+aMDtzKIY=</dsig:DigestValue>
</dsig:Reference>
</dsig:SignedInfo>
<dsig:SignatureValue>ptO...E9Q==</dsig:SignatureValue>
<dsig:KeyInfo>
<wsse:SecurityTokenReference
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
xmlns:wsse11="http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
wsse11:TokenType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"
wsu:Id="str_U1sjQ5j8JtKnObLk">
<wsse:KeyIdentifier
EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary"
ValueType="http://docs.oasis-open.org/wss/oasis-wss-soap-message-security-1.1#ThumbprintSHA1">h5...ow=</wsse:KeyIdentifier>
</wsse:SecurityTokenReference>
</dsig:KeyInfo>
</dsig:Signature>
Can someone explain me how to do the signature for such token? The step-by-step description of the algorithm, or an example using any language/library will be good.
In this document is the description of the transformation, from page 38, but I am unable to understand how to apply it in practice.
OK, after checking Oracle's WebLogic server debug and verbose log file having a working service example and setting the flags -Dweblogic.xml.crypto.dsig.debug=true -Dweblogic.xml.crypto.dsig.verbose=true -Dweblogic.xml.crypto.keyinfo.debug=true -Dweblogic.xml.crypto.keyinfo.verbose=true -Dweblogic.wsee.verbose=* -Dweblogic.wsee.debug=* (more info here, here, here and here), thank God there was a preety good insight on how the security token was de-referenced. Basically, having a SecurityTokenReference for an x509 certificate, with a KeyIdentifier, is dereferenced as a BinarySecurityToken in this way:
<wsse:BinarySecurityToken xmlns="" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3">CertificateBase64String</wsse:BinarySecurityToken>
Some important things to notice are:
The ValueType, and thus the content of the BinarySecurityToken, is defined by the TokenType of the SecurityTokenReference. In this case, the text of the BinarySecurityToken is the x509 certificate that is referenced by the KeyIdentifier element, encoded as a base64 string.
According to the specification, the BinarySecurityToken only includes the ValueType attribute. So it should not include the EncodingType attribute, neither the Id attribute that the SecurityTokenReference has.
The same namespace prefix of the SecurityTokenReference is used. Also, the namespace for this prefix is included in the tag.
The default namespace attribute is set as empty: xmlns=""
So basically the whole SecurityTokenReference element is replaced by the new BinarySecurityToken, and this is the one to be canonicalized and hashed (to get its digest value). Beware that it is canonicalized and digested as is, so the operation may provide a wrong result if the XML is simplified by removing the empty xmlns namespace or the prefix namespace, or by changing the namespace prefix.
The example BinarySecurityToken is already canonicalized using the algorithm "http://www.w3.org/2001/10/xml-exc-c14n#", so in .NET, to get the DigestValue using the digest algorithm "http://www.w3.org/2001/04/xmlenc#sha256", is enough to do this:
System.Security.Cryptography.SHA256 sha = System.Security.Cryptography.SHA256.Create();
byte[] hash = sha.ComputeHash(Encoding.UTF8.GetBytes("<wsse:BinarySecurityToken xmlns=\"\" xmlns:wsse=\"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd\" ValueType=\"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3\">MIIF...2A8=</wsse:BinarySecurityToken>"));
string digestValue = Convert.ToBase64String(hash);
I wonder why we have to load an ontology, also provide its namespace while querying it? Why loading the ontology is not enough?
To understand my question better, here is a sample code:
g = rdflib.Graph()
g.parse('ppp.owl', format='turtle')
ppp = rdflib.Namespace('http://purl.org/xxx/ont/ppp/')
g.bind('ppp', ppp)
In line 2, we have opened the ontology (ppp.owl), but in line 3 we also provided its namespace. Does namespace show the program how to handle the ontology?
Cheers,
RF
To specify an element over the semantic web you need its URI: Unique Resource Identifier, which is composed of the namespace and the localname. For example, consider Person an RDF class; how would you differentiate the Person DBpedia class http://dbpedia.org/ontology/Person from Person in some other ontology somewhere? you need the namespace http://dbpedia.org/ontology/ and the local name Person. Which both uniquely identify the class.
Now coming back to your specific question, when you query the ontology, you might use multiple namespaces, some namespaces may not be the one of your ontology. You need other namespaces for querying your own ontology, e.g. rdf, rdfs, and owl. As an example, you can rarely write an arbitrary query without rdf:type property, which is included under the rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns> namespace, not your ontology namespace. As a consequence, you need to specify the namespace.
Well, now as you should know why to use a namespace, then we can proceed. Why to repeat the whole string of the namespace each time it is needed? It is nothing more than a prefix string appended to the local names to use in the query, to avoid writing exhaustively the full uri. See the difference between <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> and type.
Edit
As #AKSW says, as a conclusion, there is no need to declare a namespace in order to work with the ontology but it increases the convenience when working quite often with resources whose URI has particular namespace.
I am using logback with a third party package which sets an identifier in the MDC when its code is running. The rest of the time, this identifier is not set. So if I use a PatternLayout of [%X{id}] %m%n, then I see messages like
[Foo] Foo running
[Bar] Bar running
for messages related to the package. However, the rest of my log statements look like
[] Thing happened
The %X{id} is useful information when it exists, but I would like the logger name to be used when it is not. I tried
[%X{id:-%logger{20}}]
and
[%X{id:-logger{20}}]
but neither used the logger name as a default value.
I could write a custom layout that sets id to the logger name if it is not set, forwards to the layout and then clears field. Is there a simpler way to do this?
Imagine an instance of some lookup of configuration settings called "configuration", used like this:
if(! string.IsNullOrEmpty(configuration["MySetting"])
{
DoSomethingWithTheValue(configuration["MySetting"]);
}
The meaning of the setting is overloaded. It means both "turn this feature on or off" and "here is a specific value to do something with". These can be decomposed into two settings:
if(configuration["UseMySetting"])
{
DoSomethingWithTheValue(configuration["MySetting"]);
}
The second approach seems to make configuration more complicated, but slightly easier to parse, and it separate out the two sorts of behaviour. The first seems much simpler at first but it's not clear what we choose as the default "turn this off" setting. "" might actually a valid value for MySetting.
Is there a general best practice rule for this?
I find the question to be slightly confusing, because it talks about (1) parsing, and (2) using configuration settings, but the code samples are for only the latter. That confusion means that my answer might be irrelevant to what you intended to ask. Anyway...
I suggest an approach that is illustrated by the following pseudo-code API (comments follow afterwards):
class Configuration
{
void parse(String fileName);
boolean exists(String name);
String lookupString(String name);
String lookupString(String name, String defaultValue);
int lookupInt(String name);
int lookupInt(String name, int defaultValue);
float lookupFloat(String name);
float lookupFloat(String name, float defaultValue);
boolean lookupBoolean(String name);
boolean lookupBoolean(String name, boolean defaultValue);
... // more pairs of lookup<Type>() operations for other types
}
The parse() operation parses a configuration file and stores the parsed data in a convenient format, for example, in a map or hash-table. (If you want, parse() can delegate the parsing to a third-party library, for example, a parser for XML, Java Properties, JSON, .ini files or whatever.)
After parsing is complete, your application can invoke the other operations to retrieve/use the configuration settings.
A lookup<Type>() operation retrieves the value of the specified name and parses it into the specified type (and throws an exception if the parsing fails). There are two overloadings for each lookup<Type>() operation. The version with one parameter throws an exception if the specified variable does not exist. The version with an extra parameter (denoting a default value) returns that default value if the specified variable does not exist.
The exists() operation can be used to test whether a specified name exists in the configuration file.
The above pseudo-code API offers two benefits. First, it provides type-safe access to configuration data (which wasn't a stated requirement in your question, but I think it is important anyway). Second, it enables you to distinguish between "variable is not defined in configuration" and "variable is defined but its value happens to be an empty string".
If you have already committed yourself to a particular configuration syntax, then just implement the above Configuration class as a thin wrapper around a parser for the existing configuration syntax. If you haven't already chosen a configuration syntax and if your project is in C++ or Java, then you might want to look at my Config4* library, which provides a ready-to-use implementation of the above pseudo-code class (with a few extra bells and whistles).