I had a quick question about an abnormal ways to buy ERC-20 Tokens and hear if this is technically possible.
Let's assume there is a smart contract that generates and holds ERC-20Token called 'ThankYou' token, which has a supply of 1 billion tokens.
1) User A donates 100ETH to a child in need.
2) Smart contract detects that User A has donated 100 ETH and validates that 100ETH indeed has been sent to the child
3) Smart contract is triggered to send 30ThankYou tokens to User A for doing good.
I would very much appreciate your thought on this. I only came across cases where ERC-20 Tokens are attained by 'buying' with ETH (based on the price of ERC-20 Tokens). I was wondering if above step I mentioned is possible. And If yes, then can User A sell that 30ThankYou tokens for a exchange with ETH.
Thank you,
No, I don't think it is possible for a smart contract to listen for an event.
You could however write a web application, that would listen for an event and then call the function in your smart contract remotely. But this would have to happen, off blockchain.
Other than that, you could implement a function askForThanks(), that would check wether or not a user has donated a certain amount of ether in the past and send him ThankYou Tokens accordingly.
And If yes, then can User A sell that 30ThankYou tokens for a exchange with ETH.
If people are willing to buy ThankYou Token (although I think that would deminish the whole purpose of your token) you could certainly than trade these Token, like any other ERC20 Token.
Related
We have a query to ask regarding the Twilio voice communication and hope you will help us.
We are having a client and they are having business with Health care domain having Doctor-Patient communication happening through Twilio cloud.
We know that a non-twilio number can be used for caller id after verification with twilio by 6 digit input from the user.
The client requires a mechanism like when they sell the product to many customers, each customer just input any valid work number (office number) and wants to use those number as Caller Id without the verification process.
We would like to know whether Twilio us offering such custom caller ids without doing the verification steps ? Like with means of a high-level membership plan with twilio or for utlizing any bulk purchase schemes or by trusting the client with any documents or by any other means of ?
Please give your suggestions in this.
Thanks
No. You need to verify each number to use it for your caller ID. Another way of doing it is that you buy the number via Twilio when the customer signs up and that's their outbound caller ID. Would be much easier to do.
david
I'm a Freelance developer creating a site for a start-up company.
Getting PCI compliant at this time is going to be tough, since the site is still in major development and the funds are quite short.
The situation is this: They want to accept payments on demand in a fast and easy way. This is going to involve punching an id followed by a PIN into a virtual pinpad. This should process the transaction, charge the card, and be done. Because we are not currently PCI compliant, I would like the security to be as follows:
User, in Account Management, can click a link to redirect to the third-party payment processor (We are currently using Authorize.Net). On this page, the user enters their card information followed by email/some form of ID. Their card is saved through this third-party, and the third-party sends us their ID for the user as long as the user email (Or whichever identification used on our end). Now, when the user wants to create a transaction, we send the User ID, our API Key, and the transaction Key used by the third-party as well as the amount to charge. They charge the account and all is good.
Anybody have experience in this? Is this possible? Other solutions are welcome. Again, the company is slightly low on funds, and the transactions are usually going to be ~$10. They are currently working through 100% cash right now and averaging about 30 transactions a day, which is expected to increase drastically over the summer.
Unfortunately, with the new DSS 3.1, you may still need to perform a SAQ A-EP. Part of the requirements for the SAQ A-EP are:
Your e-commerce website does not receive cardholder data but controls how consumers, or their
cardholder data, are redirected to a PCI DSS validated third-party payment processor
Even though your site never takes or processes credit card data, since your site does perform a redirect, that redirect could be changed to point to a malicious site.
Further information can be found in the SAQ A-EP.
I'm currently working on an iOS app where I would like to control the user experience of the entire checkout process when the user is paying directly by credit card. The PayPal iOS SDK doesn't quite fit my use case as it has a baked in ViewController that must be displayed to complete the payment.
The PayPal REST API's appear to allow me to charge a user's card directly but would require my secret key in the process implying it should only be used for some server side flow.
The PayPalPaymentViewController does have an option to take credit card payments directly from the user so I wonder if these services being used to accomplish this are publicly available?
First, I'd be curious as to why the provided view controller is inadequate. The goal is to provide a minimal interface in which to accept credit cards.
But, yes, these services are publicly available. A limited set of functionality (e.g. sale transaction) is possible by omitting the OAuth2 secret.
However, you will still want to verify the transaction on your own server in order to avoid being spoofed by a malicious user.
Don't try to replace the paypal ViewController with anything else, you might run into lots of legal trouble. For example, here in germany, the size and text of the "purchase" button is regulated by law. Paypal's Lawyers have checked the german version of the ViewController for correctness. If anyone, in germany, uses your app, and makes purchases with a different UI, chances are very high that a) the transaction is void and b) german authorities will prosecute you for fraud. Don't risk that.
So, I was wondering, since users send their APNS tokens to the APNS provider in order to receive push notifications, should the tokens be encrypted? Is SSL necessary?
From what I figure is that there is no real sensitive data in the token. If someone actually managed to sniff the token from a user, he still would have to obtain my push certificate. And if he managed to do that (he won't ;-)) all he could do is send spam notifications to this particular user. Is that correct? Or did I miss something?
Also, I assume that it's not possible to identify a device (or more importantly, its user) based on an APNS token?
So, I want to assure that, if someone sniffs a push notification registration from one of my clients (the registration contains the APNS token and the information the user is interested in, and the connection is unencryped so everything is readable in plain text) ...
he still has to obtain my push certificate to be able to bother my client in any way
he knows that someone is interested in this information, but has no way to identify who my client is
Can I rest assured?
Thanks in advance!
SSL is almost never a BAD idea. Lack of SSL means your users will be susceptible to all sorts of nastiness like DNS poisoning, man in the middle, or sniffing.
Maybe you're worried about the cost of an SSL cert, or the overhead on your servers? I don't know - but I'm just sayin' - probably worth considering if you're getting paid to provide some service or are collecting personally identifiable information.
Otherwise your points in the post were pretty much right on. The fact is someone would need your push certificate to send out those messages to those users.
Also, I assume that it's not possible to identify a device (or more
importantly, its user) based on an APNS token?
Prior to iOS 5, that ID was consistent across all apps - so aggregate stats companies were able to use the ID to identify a specific user somewhat... at least to know "this is the same person". But that changed recently, and it's now a random per-app ID.
Let's say I am making a sign up form in which I asked user's twitter ID. How do I verify if the ID entered by user belongs to him/her? In case of verifying email we simply send a verification link which user has to click so how do I verify twitter ID? I have never used twitter before.
The only reliable and practical way to verify that twitter account X belongs to user Y this to do full on “3 legged” OAuth authentication. That being said, you may want to consider if you might be OK with just taking the user at their word on it.
Getting OAuth to work and securely storing the resulting tokens is much easier nowadays than it once was, but is still non-trivial.
Reasons to verify the twitter account, in increasing reasonableness:
You will be making enough server side requests, on behalf of multiple users, that you run up against Twitter’s API Rate Limiting. (Having multiple auth-tokens will allow for a higher API rate)
You need to automagically send tweets and/or follow accounts on the user’s behalf
N.B. do this as opt-in and be ultra clear about when/why you will be doing this, or you will face the justified fury of scorned users
Don’t verify the account if you’re looking to do these things:
You need to send tweets and/or follow accounts on the user’s behalf, and the user will be able to perform a browser based confirmation workflow for each of those actions; use Twitter’s Web Intents for this.
If you just want to pull in real time data for user’s avatar, bio, or recent Tweets Twitter supplies some prefab widgets for you.
All of the authenticated Twitter API Calls can be done client side with JavaScript. Twitter has a js framework, which does not require you to handle and store tokens on your server, to help you with that.
An alternate contact method for password resets, notifications, etc.
Private communication between users on twitter requires mutual following, many users probably never check their Direct Messages (or even know what a DM is), and any messages would be limited to 140 characters. Just use email for all that kind of nonsense.
If you’re just gathering this info to display it on a user’s profile page, in an “other places on the web” kind of way, integrating and maintaining all the server side OAuth pieces is likely too much bother. Just make sure you have a reasonable and clear TOS and an obvious way for 3rd parties to report any of your users who may be claiming a twitter account that is not their own.
If you’re still interested in OAuth, Twitter's Dev page has plenty of resources, including a nice overview of a generic “Sign In with Twitter” “3 legged” OAuth work flow.