Say, I have an interactive dapp, like a game and I want the user's actions to be saved on the blockchain (maybe these are moves in the game of chess, whatever).
So, from my understanding, options are:
Create dynamic wallet via web3, prefill it from the metamask and send as many transactions as I want.
Somehow negotiate with the user to trust the dapp and let metamask send transactions on user's behalf without pesky prompting.
What is the right option (if any)? Turns out, metamask has a whole permission escalation framework, yet I wasnt able to ask the right permission.
You can access user funds in several ways:
ask users to deposit in a smart contract and keep track of balances there
ask users to allow your smart contract to spend their tokens via ERC20 allowance
How often will user actions be saved on the blockchain?
Even if your dapp has access to all user funds via a shared wallet or ERC20 allow() + transferFrom() you'll still need somebody to trigger a transaction and pay gas fees whenever you're updating chain state.
Related
I am building a react site where users can purchase a "day", "weekly" or "monthly" pass for the content on the page. I only want to allow them access for a day if they purchase a day pass. Same for weekly and monthly. I am using JWT to keep users logged in. I have no idea how to create the functionality to verify if they should still have access or not. Would love some help. I am also using redux if that helps.
You need to start thinking about Authentication and Authorization separately. Your JWTs are (hopefully) performing the Authentication duty. The "limited access" you're asking about are the concern of Authorization. In other words: now that you know who this user is, what are they allowed to do?
You need to map your JWTs to some form of internal user id, and then determine if they can or cannot access the requested resource/endpoint/etc.
For example, you might allow all users to GET from /jobs to view the listing of job postings, but if they try to POST to /apply for a job, you verify that they are a "premium" user, with time remaining on their paid subscription.
I am new to cryptocurrency application development. I am using web3js library and reference is
https://web3js.readthedocs.io/en/1.0/web3-eth-accounts.html for managing wallet balance and multiple account address link with single wallet. How can i do this?
We want every user deposit ether comes to out(application) wallet so we can reduce transaction charges as for individual it will many times(between our app, ethernet, user address, so on) from one account to other.
Many exchanges implement an overlay SQL Database to manage account balances, as banks do.
The accounting API on bitcoin (or its' inheritance crypts) does not support that very well and it might get you confusing, which is why the accounting API has been deprecated.
You would need to:
Allow users to register accounts at your database.
Create an address using the RPC API, and associate it to the user logged in.
Monitor the user balance by logging every transaction associated to his wallets.
So I'm writing a mobile app and have reached a point where I need to allow users to register a username. I'm doing this by asking for an email address, username and password.
Typically, it's been normal to set this sort of thing up on the web by having the user confirm his email address by clicking on a link sent to his inbox.
Needless to say, on a mobile app this is a bit clunky as the user will be redirected out of your app and into his browser.
So I had a look at how other mobile apps are doing it (WP7) and was surprised to see that DropBox and Evernote both allow you to sign up without confirming your email address. The end result of this is that I was able to sign up with completely bogus email addresses and/or valid email addresses that don't belong to me.
I assume this is done on purpose.
Your thoughts?
I came across the same issue when writing a social networking style app. I chose to have the user create a username and then provide and email and password. I do not verify the email address and I've never attempted to send any email to them (yet).
What I would suggest would be alternate ways to validate a users email address. My app allows users to do Facebook Connect. All they have to do is log into Facebook, and the app talks to Facebook to confirm that they are using a valid email address. No need to verify it with a URL in an email.
I believe Twitter has a similar service and there may even be a few others that provide an API.
I've also discovered that a lot of people just want to tinker around in the app and not create an account at all. It's definitely a balancing act
I'd say it depends on your app and how important it is to ensure users have valid email addresses. In an app I'm creating now, we want to discourage users from signing up with multiple bogus accounts (because our system could be gamed that way) so we're not allowing users to log in until their email address if verified. On other sites however, it might not be such a big deal so why bother users with that extra step?
As for a mobile device, I don't see why you can't still send a verification email that sends them to your website to verify their email address. There are plenty of mobile apps that also have a website users can log into to manage their account.
Another option is have multiple "states" for users. Before they validate their email, they are in a "pending" state. Once they click it, they're in an "active" state. If you store the createDate for the user, you can periodically remove pending users older than 1 week (or however long).
The bonus is that you can easily add more states, such as suspended or deleted.
Personally, I wasn't too happy for users to create accounts with any old email address.
I think a few decent options are:
send a confirmation email with a link that uses a Custom Url Schema to redirect back to the app (although this is only good if they use the link on the same device)
send a short PIN in the email for them to enter back in the app.
send a confirmation email with a web link, have your server confirm the valid email/token, and have your app check the account status either periodically or with some sort of realtime tech like SignalR or Firebase.
I prefer the last one, although hardest to implement. A user might well have their phone in their hand and their laptop next to them, register in the app and try to click the link in the email that just showed up on their laptop. I like the idea of the app then just "knowing" that they've validated.
Do you have a web server? Write a web service that does the validation for you on the server side, and sends back the result.
Either you can use some platform, such as Facebook connect as #Brian replied above, or you may give users a reasonable timeframe to verify, for example, a few days or even a week. After that, the account gets removed.
You can even have your app issue notifications to remind the user to verify his account (such as every day, or on the last date of the verification.
Don't ask for email confirmation on mobile and allow the user to use the service. When the user is using a PC, then ask the user to confirm his email.
I won't defend my recommendation because most of the solutions here are valid. There isn't one correct way. You asked for ideas and here's one.
A good strategy is to allow people to use as much of your app as possible given the amount of data they've provided.
For example, in the case of a newsreader you might let someone browse your app without registering, then require an account for offline syncing, and a verified email for alerts. Always give people a good reason to take the next step, and build engagement first, then people will forgive you pestering them later.
How to know if a user is currently logged-in in your Google App Engine application?
The application allow its users to browse other users' profile. If the viewed profile is also using or logged-in in the application, i want a notification that the viewed profile is online.
How to achieve this requirements?
If you are managing user profiles, you know when a user logs in. At the end of the login process, just save the user's log-in information in the memcache somehow.
You will later be able to check if a user is logged-in just by searching for him in your memcache.
This way is easy to catch and track the connection events, but you also have to react when a user disconnects, to have your list up to date. To achieve this, you can use a Channel. See the google documentation.
You could, as Gaël suggests, use the Channel API to track this, but it's probably overkill. If you wanted to go that route, just listen for the connected & disconnected messages, and update a field in the db that indicates that the user is signed in.
A less expensive route might be to just update a field in your user's record that's something like "last time this user requested a page." If it's been more than n minutes since the last time the user requested a page, assume they're signed out. Indeed, you could even do this in memcache with a map from userid to last access time.
It comes down to what you want to do with the "signed in" information: if you just want to give a general sense of whether a user's around, or how many users are online, using the datastore or memcache solution is probably good. On the other hand, if you want to reflect the user's presence so they can respond to eg. IMs, then you'll probably want the Channel API anyway so you can immediately deliver messages to them.
I have a business requirement that calls for an end user to be able to login to an e-commerce system with a one-time use password, purchase a course, and then never be able to login again. At the moment the company that is allowing their employees, my client's students, is going to generate that password for them and send me a list of the passwords they are generating.
I do not like the concept but I have yet to come up with a better one that will work for all parties. If something happens mid-purchase they have to go back to the company to get new login credentials.
The ability to purchase a course cannot be open to the public, it has to be through the e-commerce portal, and for the moment there is only one company participating but there will be more in the future. I am seeing this as a total maintenance nightmare.
My question is has anyone run across this before, if you wouldn't mind sharing tell me how you solved it, or point me in a direction that will give me some insight. I have googled the concept to death and have not come up with any bright ideas.
You can't resolve the "problem during purchase" issue yourself - They need to modify their service so that the password is destroyed when the transaction completes.
No matter what you do with regards to the password, once the user is logged in, the password is disabled on their servers. After that, you have no control.
They should either:
Cancel password on transaction completion
Provide you with an API/Web service to allow you to request a new key.
I have the answer for this one and document it here for my own personal OCD completion purposes. I created a login form that allows for a two part key; username is based on company name plus internal company ID(not a guid), paired with a password that is cryptic key, ex: #SCD6-, plus employee id generated by the company. The rub is I don't know what the employee ID is, and only use it because it should be unique although it doesn't matter if it is not, once the user logs in once completes the only marginally secure process then checks out the login is invalid and can never be used again, unless manually unlocked (in case of a duplicate employeeID at some time in the future, which is unlikely). The username and key is emailed to the employees of the target company, which is generated by the target company.If I do have the employeeID in the system which is 50/50 then I can pre-fill the forms out.
The only thing this lock protects is a process and not secure information so I am not too worried about security and it's only real purpose is to keep John Q, from stumbling onto the process and paying money that my client would need to refund later. If it were a secure data process I would not use this method.