DialogFlowCX does not provide sys.person.
Neither last_name nor given-name is provided.
Is sys.person obsolete?
I am using Japanese.
image
The problem is not with the language used, but with the agent's region and data residency compliance.
For U.S. regions, Data residency compliant setting defaults to false, and can be changed to true. For other regions, the setting is set to true, and it cannot be changed.
Some system entity types are not data residency compliant yet. If you need compliance for these entities, consider using #sys.any until support is added. For example, where you would normally use #sys.person, create two form parameters, given-name and family-name, with a #sys.any entity type. The agent can prompt for these values individually when form filling.
Related
I am trying to implement an authorization system based on general NFC tags. One of the concerns I want to address is tag cloning. I have read some literature ensuring tag authenticity by using a read-only tag ID written on the tags during manufacture. This ID is signed by the owner and written on the tag. This way, a cloned tag (which will have a different, tag-manufacturer assigned ID) can be detected by comparing tag IDs with the cloned signature.
My question is, is it safe to assume that all (or most) NFC tags will have such a coded-in, read-only ID which I may use for cloning detection?
Narrow your problem down first pick a tag type and manufacturer that is suitably secure for your needs.
A UID is a general property of most tags BUT different tags have different specifications. Some tags have a small UID size and thus UID re-use is likely. Different tags have different length UID's. Some are supposed to be set at the factory but clones allow them to be set later. Some specification state the tag UID is always writeable.
Also using Host Card Emulation, it possible to write program to brute force any security based on UID alone (time taken could vary depending on UID length used)
Various tags offer password protection and encryption of the data on the tag (older tag types can have weak encryption/password protection though).
Most of the of the password protection is done with a special area where a password can be written to by a Reader/Writer but can only be read by the tag itself.
If you do use the password protection features of some tags make sure you don't the same password for every instance of the system, make sure the Admin of the system is forced to set one for their systems.
Considering UID for authenticity check is not a good idea, because cloned cards can have the UID cloned exact same as that of original card.
I'm not sure about other manufacturers, but as I have worked a lot with NXP tags, I'm just gonna suggest a solution here, if that suits your requirements then you can go ahead. For working with NXP cards they have provided an open api called TapLinx, where you get an api for originality check. Using which you can get to know if the card is authentic or cloned. It will identify the cloned cards even if the UID is also cloned.
Do not rely on the UID as security mechanism. There are cloned chips on the market, as well as chips where you can program the UID yourself. On top we have seen mistakes from manufactureres, resulting in duplicate UIDs.
Better use your own numbering scheme. Ideally on a cryptographic basis.
We want to build a distributed cache of Unique IDs to be used in an application to identify each transaction. UNIQUE ID is generated using some custom logic(say DATE +some random number) in java code.
The application runs in 8 application servers(Load balanced). Once a UNIQUE ID is consumed by the application, cache needs to be updated with the previously consumed value. So cache object update should be done in a multi threaded environment.
Is it better to keep local cache in each application server(Unique ID generation sequence specific to each Node). But that would not guarantee transaction ID sequence in the application.
We have been looking options of hazlecast, geode, ignite etc., to build distributed cache(peer to peer cache).But which one would work well when there is cache updation in multithreaded environment.
Which caching solution/model would best fit this problem.
No need for cache
You do not need a caching solution for your problem.
You can generate universally-unique identifiers without any need to coordinate between your systems.
UUID
A proper solution has already been invented, standardized, implemented, and widely adopted: UUID
A Version 1 UUID represents a point in space and time, taking the current moment along with the MAC address of the machine, and adds an arbitrary number that increments when the host’s clock is reset and Increments when the UUID generator restarts.
All this data is represented in a 128-bit value, with a specification for which bits represent which pieces of data. A canonical format for textual display to humans uses hexadecimal characters punctuated by hyphens.
Example:
1154cf8a-6f7b-11ea-bc55-0242ac130003
You asked for:
custom logic(say DATE +some random number)
As mentioned above, some versions of UUID contain just that, a date-time plus an arbitrary number plus other info. It sounds like your team is unwisely reinventing the wheel.
UUIDs are used extensively through the IT industry. You will find them in your email headers to identify each message. You will find them as transaction IDs. You will find them as object IDs.
UUID generator implementations are built into nearly all operating systems (macOS, Linux, BSD, Windows, etc.). Libraries are publicly available, such as OSSP uuid. The more powerful databases such as Postgres support UUID as a native data type for efficient storage and ease-of-use. Some software platforms such as Java include a data type for UUID and a generator implementation.
The purpose to UUIDs is that various software systems can generate UUID values on their own, on the fly, with no need for a central authority, no need for a distributed cache, and no need to coordinate with other systems.
My current understanding is that NiFi processor properties are specific to that processor. So adding a new property to a processor will only be visible within that processor and not be passed on to later processor blocks?
This is why UpdateAttribute is necessary to add metadata that stays with the flowfile as it traverses through the data flow:
So what is the value in allowing the user to add custom properties in a processor beyond the ones defined and required for that processor to execute? Is it analogous to creating variables that can then be used in other properties?
A very good question and one that comes to everyone's mind when they start working on building data-flows in NiFi.
First things first: Properties vs FlowFile Attributes
As you yourself have mentioned in your question itself, Properties are something that are used to control the behavior of your Processor while Attributes are metadata of your flow-in-action.
A simple example, lets take GetFile processor. The properties it exposes like Input Directory, File Filter, etc., tell your processor where & how to look for the source data. When the processor successfully finds some source matching your configuration, it initiates the flow, meaning a FlowFile is generated. This FlowFile will carry the content of the source data plus some metadata of the source such as the name of the file, size of the file, last modified time, etc., This metadata can actually help you down the flow with your subsequent processors like checking the file's type and route the FlowFile accordingly. And mind you, the metadata are not fixed; it differs with the different processors.
There are few core attributes which every processor would add like application.type, filesize, uuid, path, etc.,
What is purpose of letting users add custom properties when they are not added to the attributes?
It is a feature that NiFi offers to processors which they can use or ignore. Not all processors allow custom properties to be added. Only selective processors do.
Let's take InvokeHttp as an example. This processor allows the developer to create custom properties. When a user adds a new custom property, that property is added as a header to the HTTP call which the processor is going to make because the processor is built that way. It looks for any dynamic (custom) properties. If they are present, it will be considered as custom header(s) the user wants to send.
At least, in this processor's context, it doesn't make sense to capture this header data as a metadata because it may not be useful for the subsequent processors but there are certain other processors that act differently when custom properties are provided, like UpdateAttribute whose sole purpose is add any custom property as an attribute to the incoming FlowFile.
There may be absolutely no way to do this, and it might also be frowned upon. When I send a html email to outlook, the user is sometimes asked if they want to download the images and sometimes they just load. My first question is why is that? And my second question is, is there a way to prevent outlook from asking and have the images auto download, or is that something only the user can do?
If the images are embedded image attachments, there won't be a prompt.
If the HTML references external images, the message must be stamped with a special property that cannot be transmitted and can only be set locally, either by the end user or programmatically (PR_BLOCK_STATUS property - see an excerpt from [MS-OXOMSG].pdf below.
If you are using Redemption (I am its author), you can set set PR_BLOCK_STATUS property using RDOMail.DownloadPictures property: http://www.dimastr.com/redemption/RDOMail.htm
2.2.1.1 PidTagBlockStatus
Type: PtypInteger32 8
Indicates the user's preference for viewing external content (such as links
to images on an HTTP server) in the message body. A client MAY ignore this
value and always allow or block external content based on other factors
(such as whether the sender is on a safe list). If this property is used,
then the default action is to block the external content. However, if the
value of this property falls within a certain range, then viewing external
content is allowed. The allowed value is computed from
PidTagMessageDeliveryTime: since the sender of a message does not have
knowledge of this value, the sender cannot reliably set PidTagBlockStatus to
the allowed values.
To compute the allowed values, convert the value of
PidTagMessageDeliveryTime to a PtypDouble, floatdate, where the date is
represented as the number of days from midnight, December 30, 1899. Apply
the following formula: result = ((floatdate - floor(floatdate)) * 100000000)
3; where floor(x) returns the largest integer ? x. Convert the PtypDouble
value result to a 32-bit integer computedvalue. Clients SHOULD set
PidTagBlockStatus to computedvalue to allow external content. However, when
determining whether to accept external content, clients SHOULD allow
external content if the absolute value of the difference between
computedvalue and the value of PidTagBlockStatus is 1 or less.
I'm querying a bunch of information from cisco switches using SNMP. For instance, I'm pulling information on neighbors detected using CDP by doing an snmpwalk on .1.3.6.1.4.1.9.9.23
Can I use this OID across different cisco models? What pitfalls should I be aware of? To me, I'm a little uneasy about using numeric OIDs - it seems like I should be using a MIB database or something and using the named OIDs, in order to gain cross-device compatibility, but perhaps I'm just imagining the need for that.
Once a MIB has been published it won't move to a new OID. Doing so would break network management tools and cause support calls, which nobody wants. To continue your example, the CDP MIB has been published at Cisco's SNMP Object Navigator.
For general code cleanliness it would be good to define the OIDs in a central place, especially since you don't want to duplicate the full OID for every single table you need to access.
The place you need to be most careful is a unique MIB in a product which Cisco recently acquired. The OID will change, if nothing else to move it into their own Enterprise OID space, but the MIB may also change to conform to Cisco's SNMP practices.
It is very consistent.
Monitoring tools depend on the consistency and the MIBs produced by Cicso rarely change old values and usually only implement new ones.
Check out the Cisco OID look up tool.
Notice how it doesn't ask you what product the look up is for.
-mw
The OIDs can vary with hardware but also with firmware version for the same hardware as, over time, the architecture of the management functions can change and require new MIBs. It is worth checking whether any of the OIDs you intend to use are in deprecated MIBs, or become so in the life of the application, as this indicates not only that the MIB could one day be unsupported but also that there is likely to be improved, richer data or access to data. It is also good practice to test management apps against a sample upgraded device as part of the routine testing of firmware updates before widespread deployment.
An example of a change of OID due to a MIB being deprecated is at
http://www.cisco.com/en/US/tech/tk648/tk362/technologies_configuration_example09186a0080094aa6.shtml
"This document shows how to copy a
configuration file to and from a Cisco
device with the CISCO-CONFIG-COPY-MIB.
If you start from Cisco IOS® software
release 12.0, or on some devices as
early as release 11.2P, Cisco has
implemented a new means of Simple
Network Management Protocol (SNMP)
configuration management with the new
CISCO-CONFIG-COPY-MIB. This MIB
replaces the deprecated configuration
section of the OLD-CISCO-SYSTEM-MIB. "
I would avoid putting in numeric OIDs and instead use 'OID names' and leave that hard work (of translating) to whatever SNMP API you are using.
If that is not possible, then it is okay to use OIDs as they should not change per the SNMP MIB guidelines. Unless the device itself changes but that requires a new MIB anyway which can't reuse old OIDs.
This is obvious, but be sure to look at the attributes of the SNMP MIB variable. Be sure not to query variables that have a status of 'obsolete'.
Jay..
In some cases, using the names instead of the numerical representations can be a serious performance hit due to the need to read and parse the MIB files to get the numerical representations of the OIDs that the lower level libraries need.
For instance, say your using a program to collect something every minute, then loading the MIBs over and over is very inefficient.
As stated by others, once published, the name to numerical mapping will never change, so the fact that you're hard-coding stuff into your programs is not really a problem.
If you have access to command line SNMP tools, check out 'snmptranslate' for a nice tool to get back and forth from text to numerical OIDs.
I think that is a common misconception (about MIB reload each time you resolve a name).
Most of the SNMP APIs (such as AdventNet, CMU) load the MIBS at startup and after that there is no 'overhead' of loading MIBs everytime you ask for a 'translation' from name to oid and vice versa. What's more, some of them cache the results and at that point, there is no difference between name lookups and directly coding the OID.
This is a bit similar to specifying an "IP Address" versus a 'hostname'.