Can you create a whitelist/blacklist in general?
Can you create a whitelist/blacklist specifically for receiving/declining ETH or Tokens?
Can you let the transfer of ETH or Tokens fail?
Can you create subgroups for the safe owners, like 1 from {A,B,C} and 1 from {D,E,F} to sign a transaction?
Couldn't find anything on the site
Related
I've a question re how to cater for a specific scenario in the security model of D365/CRM.
Say we have User 1 and User 2 that are in the same business unit.
User 1 has full Business Unit read access to contacts.
User 2 has just user level read access to contacts.
We want User 1 to have visibility of all contact records that are available to all users in that business unit.
Using the OOB D365 security model - if somebody shares a contact with User 2 that is owned by a user from a another business unit, User 1 cannot see this contact record.
I'm just wondering what the best/cleanest way to resolve this requirement is?
Thank you
Just exploring options at this point. I believe one option is to create a team for the business unit that only user 1 gets added to and then also sharing the record with the team would work - but that seems to involve a lot of overhead in terms of maintaining shares etc.
Was hoping there might be a cleaner way to implement somehow using OOB functionality that I may not be fully aware of.
I am using Google Analytics 4 (GA4) on the client to track a whole bunch of different events. However, there are 2 scenarios that I can't cover client side:
A user completing check out on a payment page hosted by a third-party (Stripe in this case).
A refund that is made by the support team.
These events are handled by the server using webhooks. To me it seems like the most straightforward solution, would be to let the server send the event to GA4 (as opposed to the client sending it). I believe the Measurement Protocol should be used for this.
For each event submitted through the Measurement Protocol a client_id is required. When the client is submitting an event, this is an automatically generated ID which is used to track a particular device.
My question thus is, what should the client_id be when submitting an event server-side?
Should the same client_id perhaps be used for all events, as to recognize the server as one device? I have read some people proposing to use a randomly generated client_id for each event, but this would result in a new user to be recognized for every server-side event...
EDIT:
One of the answers proposes to use the client_id, which is part of the request as a cookie. However, for both examples given above, this cookie is not present as the request is made by a third-party webhook and not by the user.
I could of course store the client_id in the DB, but the refund in the second example is given by the support team. And thus conceptually it feels odd to associate that event with the user's client_id as the client_id is just a way to recognize the user's device? I.e. it is not the user's device which triggered the refund event here.
Another refund event example would be when user A makes a purchase with user B and user B refunds this purchase a week later. In this situation, should the client_id be the one of user A or of user B? Again, it feels odd to use a stored client_id here. Because, what if user A is logged in on two devices? Which client_id should be used here then?
Great question. Yes, your aim to use Measurement Protocol is a proper solution here.
Do not hardcode the client id. It's gonna be a hellish mess in reports. The nature of user-based reporting (which GA is) demands client ids to uniquely identify users. To your best ability.
GA stores the client id in a cookie. You should have convenient and immediate access to it on every client hit to BE. The cookie name is _ga. GA4 appends the measurement id to the cookie name. Here, google's docs on it: https://developers.google.com/analytics/devguides/collection/analyticsjs/cookie-usage But you can easily find it if you inspect "collect" hits and look at their payloads. There's another cookie named _gid that contains a different value. That would be a unique client id. Set it too if you can, but don't use it for the normal client id. It has a different purpose. Here how the cookie looks here, on stack:
And here it is in Network. You will need it for proper debugging. Mostly to make sure your FE client ids are the same as BE client ids:
Keep an eye on the cases when the cookie is not set. When a cookie is not set, that most frequently means the user is using an ad-blocker. Your analysts will still want to know that the transaction happened even if there's a lack of context about the user. You still can track them properly.
3.1 The laziest solution would be giving them an "AnonymousUser" client id and then append a random number to that so that it would
both indicate that a user is anonymous and still make it possible
for GA to separate them.
3.2 A better solution would be for you to make a fingerprint client id for such users, say, hashing a concatenated string of their
useragent+ip+locale+screen resolution, this is up to your analysts
to actually work on the definition of a unique user if the google
analytics library is unable to do it.
3.3 Finally, one of the best solutions for you would be generating a client id on your own, keeping GA's format and maybe adding an indicator there that it has been generated on your end just for easier debugging in the Future and setting it as a cookie, using it instead of _ga. Just use a different cookie name so that ad-blockers wouldn't know to block it.
If you want to indicate that a hit was sent through the server, that's a good idea. Use custom dimension for that. Just sync it with your analysts first. Maybe they wouldn't want that, or maybe they would want it in a different dimension.
Now, this is very trivial. There are ways to go much deeper and to improve the quality of data from here. Like gluing the order id, the transaction id, the user id to that, using them to generate client id, do some custom client tracking for the future. But I must say that it's better than what more than 90% of, say, shopify clients have.
Also, GA4 is not good enough for deeper production usage. Many things there are still very rudimentary and lacking. I would suggest concentrating on Universal Analytics and having GA4 as a backup for when Google makes GA4 actually good enough to replace UA. That is, unless you're downloading your data elsewhere and not using GA's interface for analysis.
It seems that this page (Relevant portion in the screenshot below), advices to either send the data along with the client_id or user_id. However fails to address the fact client_id is a mandatory field as stated here.
I believe it is probably safe to assume that randomly generating this field should work. At least it seems to on my end however be warned that I am unsure if this has any impact on attribution.
* In the above image, Device ID refers to client_id
How to create a room using rest API in mesibo so that we can generate the room id and secret and send it to users. Basically, the use case is
I want to use mesibo for the tutoring sessions. So we need a way to be able to create a link within the tutoring app that will bring the user directly into the correct conference. The Mesibo demo currently asks for the person's name, room number, etc. We don't want any questions asked. It should go straight from the application portal to the Mesibo conference. So the link can contain the encrypted information about the conference, such as the person's name, the room number, and the start time. Once the tutoring session is over, the links should stop working; each link should be good for only that one conference, and it should expire after.
I have successfully created the create user, regenerate user token, create group API I want to move forward to create room and let people join it.
Let me know if that's a possible cause in the documentation it's not mentioned anywhere.
a conference room is a mesibo group. The participants are members of a group. To create a conference room, you essentially need to create a mesibo group and add participants to it. Refer to the documentation here, it has one entire section on creating room using APIs
https://mesibo.com/documentation/api/conferencing/
I'm currently working (I basically new in firebase) on an android app that uses Firebase Realtime Database.
As I'm concern that how much storage I have against my email in firebase?
As described in Documentation:
One path can have maximum 32 level(or child?) deep
But It doesn't say how much storage I can get in total!
But I just tried for more than 32 child for a path and I just made 37+ child in a single path and it is still working (a bit slow). Then what does it mean by 32 level? I might get wrong understanding!
So basically I have two question to know:
How many child (or level?) can I have in a certain path?
How much storage I have against my email? As you know one email can have 15 GB in google drive! So how much in firebase?
Thank you in advance!
The 32 levels referred to are levels of nesting of database nodes. Each node would probably be representing an entity, for example:
Level 1 node - Country
Level 2 node - City
Level 3 node - Hotel
Level 4 node - Room
Level 5 node - Room Content
That is only 5 of the possible 32 levels of nesting.
On each of those levels you can have millions of instances. Each Hotel can for example have hundreds of Rooms.
You should not focus on the 32 levels as it is not recommended to nest too deeply, personally I try never to go below Level 4.
I want to create a smart contract and launch it for ICO. I also create a website where people can buy my token. I want know how to check how many token been sold (live)? so i can create a live bar counter to show how many percentages of the token already been sold.
Or is there a way i can monitor the token sale process in the smart contract?
A token contract is no different than any other smart contract. There are no special built in Solidity features or logic associated with them. They are just regular smart contracts that follow a specification.
So, if you want access to the number of tokens sold, you code that into your contract. While tokens sold is not part of the standard ERC20/ERC721 interface, nothing prevents you from adding a constant function to retrieve this information. In fact, if you're using the basic Zeppelin Crowdsale contract, you can just calculate it using the public state variables weiRaised / rate (Chances are you should be creating your own Crowdsale subcontract, so it's better to add the functionality you want there).
We can use the Etherscan Developer API to review transactions against a given contract address and find out the total supply or number of items available for sale.
There is a lot you can do with the Etherscan Developer API. For example, here's one URL that pulls data from Ethereum Mainnet -> Etherscan -> JSON parser -> Shields.io and renders it as an image to calculate the number of Su Squares remaining for sale:
Source: https://img.shields.io/badge/dynamic/json.svg?label=Su+Squares+available&url=https%3A%2F%2Fapi.etherscan.io%2Fapi%3Fmodule%3Daccount%26action%3Dtokenbalance%26contractaddress%3D0xE9e3F9cfc1A64DFca53614a0182CFAD56c10624F%26address%3D0xE9e3F9cfc1A64DFca53614a0182CFAD56c10624F%26tag%3Dlatest%26apikey%3DYourApiKeyToken&query=%24.result
^ I don't know if SO is going to cache the image here. But that URL is a live URL which pulls the number of Su Squares available hot off the blockchain.