I have a question. Outlook add-in.
The itemId value is strange from 3 days ago. We are using the office.js provided by Microsoft.
It was developed as an official document.
Issues
The results for Office.context.mailbox.item.itemId code are different on mobile and PC.
Mobile
AAkALgAAAAAAHYQDEapmEc2byACqAC/EBBBBBBiI2N+M9RJ0CDShuowvXKcwACJekCOwAA
PC
Result: AAMkAGM1ZDc2YjFjLWExODUtNGVkNC1hNDBBBBABEAMSxr1XgSL8NM2 + Hy8n2BwByK7vlr7ySQpFsplYmphCiAAAAAEMAACIjY34z1EnQINKG6jC9cpzAAIl6LODAAA =
The same code, but the results are different.
Thank you for your reply.
There are two kinds of entry IDs:
A short-term entry identifier is assigned by a service provider to an object when the identifier must be constructed quickly and does not need to last over time or distance. The uniqueness of a short-term entry identifier is guaranteed only over the life of the current session on the current workstation. Typically, a short-term entry identifier is valid only until the object that it represents is released. Clients quickly acquire, use, and discard short-term entry identifiers. For the most part, they can be used in the same manner as long-term entry identifiers.
A long-term entry identifier is assigned by a service provider to an object when an object requires an identifier with a prolonged lifespan. Long-term entry identifiers are always valid for weeks or months and can be valid on other workstations, depending on the provider. The long-term identifiers created by address book providers for custom recipients are universally valid. Long-term entry identifiers must be unique across all message stores in the active profile; therefore, when a message or folder is copied from one message store to another, it must be assigned a new entry identifier. When a message store object is moved, the message store provider that implements the move determines whether the original entry identifier will remain valid. Some service providers assign new entry identifiers to moved objects; others do not. If there is a change, the new entry identifier will be included in the information passed to clients when they are notified of the move.
We have exactly the same problem.
Worse it that it is currently different on one mobile device to another. i.e. some mobile devices are still returning the long code and consequently are working.
I don't overly care about getting a 'short code' but you can NOT reference the object using the 'short code'.
Therefor 'short code' = Broken Microsoft Outlook on mobile devices.
This is not a "minor" issue as it has rendered our plugin inoperable on mobile devices.
Related
https://docs.near.org/docs/concepts/account#account-id-rules says that account IDs must be 2 to 64 characters, and currently MIN_ALLOWED_TOP_LEVEL_ACCOUNT_LENGTH = 32, so top-level accounts of 32 to 64 characters are available without needing to be purchased at auction.
It also says:
Currently all mainnet accounts use a near top-level account name (ex example.near)
My guess is that "currently" means not just that there don't happen to be any other top-level accounts now but that there cannot be until a future change in NEAR protocol.
Where can I see the source code related to this statement?
And is there a public roadmap / timeline somewhere stating when (auctioned and non-auctioned) top-level accounts will become available?
given how account and account names are implemented (an account is actually a smart contract) the use of "near" as as a root-level account is needed.
".near" is actually an account with a smart contract deployed on it:
https://explorer.near.org/accounts/near
Anything related to account id (names) can be found here:
https://github.com/near/nearcore/blob/master/core/account-id/src/lib.rs
I have an app in iOS and android and I'm getting the user's location in both of them! With CoreLocation for iOS and Google Maps in android... After the location retrieval, we apply reverse geocoding, to get the locality out of them... Once we do, we perform equalTo queries to find photos of a specific location...
The thing is, there are occasions where the locality of iOS, is slightly different to android's! For example, "Palaiochori" in iOS and "Paleochori" in android! Observe that two letters are different!
So, whereas the location is the same in both devices, the equalTo query will obviously fail!
What I want to know, is if there is any way to create a type of query, where we don't check for equality. Instead, we check for similarity!
Notice, that we do use cloud code, so any server-side solution is acceptable and preferred!!
Clearly the location name can not guarantee uniqueness. Two possible solutions:
Ensure consistency of your database
Store a GeoPoint for these locations. When you already have Palaiochori in your database and a user finds himself in Paleochori, before saving a new object, run a whereNear() query to see if you have near places for that location.
If you have results within a reasonable radius, ask the user: Do you mean <list of near places>? The user will likely recognize the place with a similar name, and tap on it. This way you avoid duplication.
Use a consistent location database
As soon as you have lat/lng, you could use Google Places API to ask for places near that location. Google will return a Place object with a unique placeId that you can store in your database. The id is guaranteed to remain the same and can be used for your queries reliably.
let us assume, we have a valid HCERTSTORE handle of opened certificate store. How can we determine - is opened store physical or system?
Restriction 1 - we should use CryptoAPI (C++) only.
Restriction 2 - we've successfully forgotten, what kind of store was used in CertOpenStore() call.
I don't see a way to solve this with CryptoAPI and, as the constraint 2 is artificial, don't think it was designed to address this problem. Closeable handles can't be passed around between processes, so one cannot "forget" what it was unless deliberately: the knowledge is right there, in the code that got the handle.
By looking through the function list in the left pane at CertOpenStore - MSDN, I see CertGetStoreProperty(), but there's only one predefined property, CERT_STORE_LOCALIZED_NAME_PROP_ID, which isn't reliable.
NTFS files can have object ids. These ids can be set using FSCTL_SET_OBJECT_ID. However, the msdn article says:
Modifying an object identifier can result in the loss of data from portions of a file, up to and including entire volumes of data.
But it doesn't go into any more detail. How can this result in loss of data? Is it talking about potential object id collisions in the file system, and does NTFS rely on them in some way?
Side node: I did some experimenting with this before I found that paragraph, and set the object id's of some newly created files, here's hoping that my file system's still intact.
I really don't think this can directly result in loss of data.
The only way I can imagine it being possible is if e.g. a backup program assumes that (1) every file has an Object Id, and (2) that the program is keeping track of all IDs at all times. In that case it might assume that an ID that is not in its database must refer to a file that should not exist, and it might delete the file.
Yeah, I know it sounds ridiculous, but that's the only way I can think of in which this might happen. I don't think you can lose data just by changing IDs.
They are used by distributed link tracking service which enables client applications to track link sources that have moved. The link tracking service maintains its link to an object only by using these object identifier (ID).
So coming back to your question,
Is it talking about potential object id collisions in the file system
?
I dont think so. Windows does provides us the option to set the object IDs using FSCTL_SET_OBJECT_ID but that doesnt bring the risk of ID collision.
Attempting to set an object identifier on an object that already has an object identifier will fail.
.. and does NTFS rely on them in some way?
Yes. Object identifiers are used to track files and directories. An index of all object IDs is stored on the volume. Rename, backup, and restore operations preserve object IDs. However, copy operations do not preserve object IDs, because that would violate their uniqueness.
How can this result in loss of data?
You wont get into a serious problem if you change(or rather set) object ID of user-created files(as you did). However, if a user(knowingly/unknowingly) sets object ID used by a shared object file/library, change will not be reflected as is.
Since Windows doesnt want everyone(but developers) to play with crutial library files, it issues a generic warning:
Modifying an object identifier can result in the loss of data from
portions of a file, up to and including entire volumes of data.
Bottom line: Change it if you know what you are doing.
There's another msn article on distributed link tracking and object identifiers.
Hope it helps!
EDIT:
Thanks to #Mehrdad for pointing out.I didnt mean object identifiers of DLLs themselves but ones which they use internally.
OLEACC(a dll), provides the Active Accessibility runtime and manages requests from Active Accessibility clients[source]. It use OBJID_QUERYCLASSNAMEIDX object identifier [ source ]
I'm creating a system that uses NTAG203 tags to identify accounts. The tags are formatted in the following way:
An Android app reads the tag's unique id.
The tag id is sent to a web server.
The web server creates a new account record, create a hash and salt from a combination of the new account id and the tag id and stores the hash and salt with the new account record.
The hash is returned to the Android app which then writes it on the tag.
When the tag is then scanned in future, the hash and tag id is sent to the web server for authentication.
My question is, how easy would it be to duplicate a tag like this? This would involve creating a tag with the same unique id, is this possible or can only NXP create the chips?
Creating or modifying a tag such that it is identical is probably rather hard. However, emulating such a tag is not so hard. Several hardware platforms or schematics for them that can do this can be found on the Internet.
In general, it is not a good idea to make your security depend on the uniqueness of the ID or address of a piece of hardware that was not designed for security.
You could use NDEF record type 'U' well known category type 1 (drop the http:\) or type 2 (drop the https:\) and write protect the tag after a successful write - remember that the OTP also should be set for the NDEF aspect to work else you will have either a TAG DISCOVERED or TECH DISCOVERED (which means either it has content but not NDEF else is an empty tag. Look up the NDEF standards for NFC, which are NOT part of the android framework, but is used by the framework.
Trap the tag ID (NDEF DISCOVERED or TECH DISCOVERED or TAG DISCOVERED) - if NDEF then do the server lookup, else treat as an empty tag - pass the Ident (remember its the 14A not 16A image value!) to the server for lookup, and on return perform a dead drop write (else display a button and let user press with tag present). The encoding and decoding action of the NDEF NFC will be then as per the user phone setting, and automatic by android.
The 'emulation' aspect of a ISO14443 (a,b,c) tag by a device is still in its infancy, but if an Ident is present, has got a lock field and user area that is consistent then it is fairly difficult to duplicate - but add in some obfuscation and it gets interesting. There is a requirement that certain areas cannot be written to, or the lock bits undone, will give you an idea if the tag is being emulated or not. The NTAG201/NTAG203/MIFARE tags are freely available, look on ebay.