Is there any way with a persistent state store to allow for keys in a KeyValueStore to expire? I know there is a retention period in the persistentSessionStore, but it looks like that isn't KeyValue based.
There is no expiration mechanism atm. There is Jira feature request for this though: https://issues.apache.org/jira/browse/KAFKA-4212
What you can do it though, to register a punctuation and delete data manually. You would need to store the timestamp as part of the value though and scan the whole store to find old keys.
Related
Can someone please explain the specifics of how NFT metadata is stored (both on and off chain examples?) and how it's called by apps like Opensea or Decentlraland?
Additionally, would it be especially challenging to utilize dynamic metadata for an NFT, which updates regularly based on changing smart contract variables, which themselves change due to user interactions with the smart contracts? E.g. imagine an updatable "Countdown" NFT where the jpeg shows a picture of the integer "days until X", which updates each day as time passes but can also updated based on changing X in the NFT smart contacts... made this up on the spot but actually an interesting idea? :)
Is this doable? Are there storage challenges? Do apps call metadata repeatedly or would they call it once and never reflect updates?
From my understanding you generally set a baseURI in a erc721 contract. And then if you have an auto incrementing token id. The first token will be the baseURI plus "1".
In other words:
baseURI: "https://myserver.com/api/metadata",
tokenId: 1
the token metadata is hosted at https://myserver.com/api/metadata/1
And that takes some storage off the chain, if every token has it's own unique url it adds a bit of unnecessary junk to the chain.
is it safe to only use tokens to access/change a user's data in database?
Imagine I get a request with only jwt inside of it and I want to change something for only that user using his token which is stored in database, How do I be certain that no two users have same tokens stored in database? Do I need to get his username ( another data stored in database ) and compare both of them or only token is enough?
Probablytm. The chances of users details hashing to the same string (a collision) are pretty darn small.
The header will be quite common but the payload will vary wildy, depending on the algorithm. The signature is a product of the first two so a collision depends on the payload. This has so info on that (see the accepted answer) https://crypto.stackexchange.com/questions/2558/how-many-rsa-keys-before-a-collision
The simplest answers is that it is possible but it's very very unlikely that this will happen
I am using FromCache() method whenever I need to retrieve data from the SQL database. There will be a lot of unique queries executed in a single method since it is getting data based on userID. The data associated with the userID will be updated through a separate process which will also trigger an event in the method that controls retrieving. When the data for a specific user is updated, I want to expire the cache for that user so that the next query on that userID will get the most recent data.
I see that EF plus has the option to ExpireTag. Would it be feasible to create a single tag for each userID and then use that to expire the cache?
Would it be feasible to create a single tag for each userID and then use that to expire the cache?
Yes, tag can be used similarly as if you use a cache key.
The best is probably using 2 tags:
Users
[UniqueUserId]
The Users tag will expire all cache related to "users"
The [UniqueUserId] tag will expire all caches related to this specific users
I'm in the midst of finalising the set of cmdlets for a server application. Part of the application includes security principal management and data object management, and "expiration" of both (timed and manual). After the expiration date, login and access for the security principal is refused and access to the data owned by that principal is optionally prevented (either immediately by deletion or as part of automatic maintenance by marking it as expired).
From the output of Get-Verb, I cannot see an obvious synonym for Expire, which is the most natural choice of verb for the action being undertaken here. Expire on a security principal expires the principal and may also expire all their stored data, while expire of a data object is restricted to that object.
Set- is already in use for both object types, and has a partial overlap in functionality (Expire- forces a date in the past, and removes data, while Set- will allow future or past dates but NOT remove the data).
In this fashion Expire is combining two operations (Set+Remove) and for data-security reasons, we wouldn't want to force separation into the two operations (that's already possible).
For this reason, I also consider that Disable- is not appropriate since it suggests the possibility of reversal with Enable-.
I also think Remove- by itself is inappropriate since there are data records specifically not deleted as part of the operation.
Unpublish seems very close at least for the data, but again it seems that the intent is for Unpublish and Publish to be paired, and in this case it would not be reversible. It also does not make sense when applied to the security principal.
So which (if any) standard verb would you expect to use, if you wanted to expire something?
Looking at the list of approved verbs, two jump out at me:
Deny (dn):
Refuses, objects, blocks, or opposes the state of a resource or process.
Revoke (rk): Specifies an action that does not allow access to a resource. This verb is paired with Grant.
I wouldn't worry too much if there is not a paired operation, since that happens with some of the built-in cmdlets. Stop-Computer, for example, has no paired Start-Computer. There is Remove-Variable, but no Add-Variable (there is New-Variable). I think that it is only important if a paired command exists that it is named consistently.
Another option may be to use something like a Set-ObjectExpiration/Get-ObjectExpiration especially, if it makes sense to want to query when objects are going to expire.
What about Invoke? It could be Invoke-ExpireAppObject Or something like that.
There really isn't an approved verb that fits your scenario based on MS reccomendations
what are the mitigation techniques for preventing horizontal privilege escalation through insecure direct object reference other than securing the session ? In other words, how do we achieve access controls on horizontal level, I mean the functionality, data, etc is accessible to everyone on the same level, if we are breaching privilege I feel the only possible way other than hijacking session is through Insecure direct object reference or is there any other way that I'm not aware of ?
may be use below link to prevent the Insecure Direct Object Reference: http://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/AccessReferenceMap.html
Apart from horizontally or vertically, IDOR occurs when the authorization check has forgotten to reach an object in the system. It is critical if the reached object is sensitive like displaying an invoice belongs to users in the system.
So, I advise using randomly generated IDs or UUIDs to avoid IDOR in total. The attacker has to find valid random ID values that belong to another user.
Or if this sounds hard to apply cus it's possible. Even if you use auto-incremented object IDs you can apply a hash function with salt and put in a hash map like key-value pair. Then you’ll store the key-value map in the Session.
Instead of exposing auto-increment IDs to the user, you can use hash values of corresponding IDs. When you get the value back from the user, you can find an actual ID value by looking up the key-value map in the Session. So that means, even if the attacker spoof the generated value it’s not going to exist on the map. Basically that means IDOR is not going to exploitable anymore.
To read all about IDOR and mitigation here is a post I wrote about it considering every possible aspect: https://medium.com/#aysebilgegunduz/everything-you-need-to-know-about-idor-insecure-direct-object-references-375f83e03a87