I’m building the Open-sea Dapp to practice myself. I’m just wonder if I can use Moralis and Thirdweb with each other. Is it possible? I’m connecting MetaMask with Moralis and I would like to have another page that contains the Collections that I have in Thirdweb.
GM there!
That should be possible, but seems like Moralis' functionality is overlapping a lot w/ Thirdweb, recommend that you choose either one
However, if you use our new Moralis 2.0 now we're backend focus and only provide you with APIs to index the blockchain, so that way you can just have Thirdweb used for interaction with the smart contracts
Let me know if you are not clear with this
Cheers~
First time post here, so forgive me for any bad etiquette/format.
I will preface by saying:
I have (over the last few months) been developing an iOS app for work. To be more specific, I am developing an inventory app to track bar inventory (liquor, beer, wine, etc). I can give more specifics on request if needed. I have most of the functionality done, only a couple more things I would like to implement. Eventually I will be porting it to Android as well.
At the moment, I have the model objects being archived to the local filesystem for saving and loading of data. However, my goal would be to database the model objects with the ability to display the information on a webpage. My logic is that no matter where the user is, he/she will be able to sign in to a service using a username and password, and view correctly formatted current/past inventories online. This is to allow the ability for a bartender to record the inventory, and have the bar manager view the inventory instances without having to have the physical device that recorded the inventory in his/her possession.
So here is my question:
Without being too general, what kind of service would I need to pull this off? I have a good amount of relevant front-end experience, specifically with iOS, Objective-C, HTML and CSS. However, I have ZERO experience on the back-end. I have researched around the internet, and I am aware of things such as cloud databases, web hosting and MySQL, etc. However, I cannot seem to find a definitive answer without asking my specific question. I suppose I would just like to be pointed in the right direction before investing money and time into a service that may prove useless to my cause.
Any resources and help would be greatly appreciated. Thank you!
There's not a definitive answer and you have a lot of options.
For me, the simplest is to set up a server with a database incorporated (mysql for example) and with a web service (written in PHP for example) that manages the database and queries on that.
Online you can find tons of guide on how to write a script in PHP that manages a database:
http://www.freewebmasterhelp.com/tutorials/phpmysql/2
For the iOS part you can follow also this guide:
http://www.techrepublic.com/blog/software-engineer/create-your-own-web-service-for-an-ios-app-part-one/
Good luck!
I would like to publish an app in google play, but I want to restrict the downloading under password or something like that. Is it possible? Is there any alternative?
Many thanks in advance,
Short Answer:
No.
Slightly Long Answer:
Applications available on Google Play cannot be downloaded only after a user authenticates. Any such feature will have to be implemented withing your application. At best, if this feature is needed for monetary reasons, publish a paid application.
Since the OP isn't descriptive beyond what you are looking for as a feature, it will be difficult to suggest an option / alternative that might suit your requirement. However, if you have a server setup that can communicate with the app, you can implement a feature which requires users, upon installation and running your app, to Sign Up for a new account and/or Login if already registered.
Again, I will circle back to the original point. Any such feature will have to implemented within the application itself. Google Play does not have such a feature.
I'm looking for web applications that users can use without registration, just by visiting the site, and make you register later after you spent some time.
Any good examples?
Stack Overflow; question an answer sites.
Google News; blogs and newsfeeds.
Apple's iTunes Store, Amazon; anything where you have a shopping cart.
:-)
There's this site called StackOverflow.com
Sometimes when you are looking for example sites that you've seen in the past, it is just to increase your own confidence that you are doing it right. If you have a good idea of the advantages of this style of progressive registration, why not take a moment to write down & plan out how it should work for your site?
Edit content without registration (but create a pseudo-account using IP address):
wikipedia
Register with your email address, optionally password protect your account later:
http://www.instapaper.com/
Registration as a side effect of paying for a product
Amazon (if I remember correctly)
Well, on my free time, I'm making this small web site. The site will not require to authenticate, only some actions (like leaving a comment) will require to do so.
I would expect to have up to 100 (probably less) unique visitors a day. I don't really expect more than 50% to (bother to) register.
Right now, I'm thinking of three possible authentication mechanisms (but I'm open to suggestions):
OpenID authentication;
HTTP Digest or at least HTTP Basic authentication;
My own (form based) authentication.
OpenID seems to me a little bit of an overkill for a small site like this. Also, buzzword like "OpenID" on the login page of my site might scare away the less tech-savvy people.
HTTP Digest (or Basic) authentication provides a low security level (or none at all), because the site will not be under HTTPS.
My own implementation would, most likely, suffer the same security problems as the HTTP Digest would. Although, I could implement some more protection against brute-force attacks (display a captcha after three failures etc).
What other mechanisms would you suggest? What are the pros and cons that I'm not seeing? What would you choose?
Well, if you want your visitors to leave comments I really think you're better of with something like OpenID. Because if you provide your own form based authentication who will really bother registering yet another account with some password wondering if they can trust you?
I think it's safe to say that people who like the internet own a gmail account, and all those people have an OpenID (Google account).
I suggest you use that... that's what I would do.
You haven't said what language/technology you're using. It could affect things. But I'd be inclined to just roll your own form-based authentication. It's not terribly difficult. Just remember a few basics:
Always sanitize user input. It can't be trusted;
Never store a username or password in a cookie (believe me people do);
Only store encrypted passwords using a reliable encryption method like MD5 or SHA1;
Use a non-predictable salt;
Require cookies to be enabled. Don't try and do URL rewriting.
Why not just have a name field when they post a comment, perhaps remember it in a cookie if you want. Most users just want to identify themselves not have an account.
Just make sure that you have some spam blocking in place as forms attract spam bots. Even if that is just a capcha with the form every time.
Openid is the best I think. Also if you give proer help about open id (or like SOF shows) then people will uderstand. Once less tech savvy people uderstand the use of opend id (no new username and pwd) then they will start liking it.
Definitely go with OpenID - the more people we get onboard, the more familiar people will become with it, and it's not really that strange to use the first time. If you are a microsoft dev, the dotNetOpenID library makes implementation pretty straightforward - I have done this for both ASP.NET and ASP.NET MVC sites with no problems.
EDIT:
With regard to supporting non tech-savvy users, some links / explanation on the login page would go a long way to alleviating concerns. The redirect they will see is quite similar to experiences that they are more familiar with, like credit card or paypal authorization, so should be easy to explain in these terms.
It depends in part who your target audience is. If they're all computer geeks, go with OpenID. They're either familiar with it, or will understand what you're doing. If they're not necessarily computer geeks, they may not have been exposed to OpenID authentication yet, so OpenID could present a barrier to entry. In that case, you might want to go a more traditional route, such as register/validate email/login approach, whether roll-your-own or off-the-shelf.
You could distribute some RSA SecurID to your visitors ;-)
Seriously, the main question to ask is: does the total hour of work to implement a decent security system for my users to log in are worth the content that may be accessed if the website security is broken?
You should look into RPX (https://rpxnow.com/), its a layer on top of OpenID and a few other schemes that for most languages is really easy to implement (there is a gem for ruby and I know a friend of mine got it into his php application in a less than a couple of hours).
OpenID rules! As an informed user I'm not sure it's been looked at to the point where it's "bulletproof" for security, so I probably wouldn't use it for financial / medical websites, but for the 95% of other websites, it would save me from having to write down my cheat-sheet of 137 different usernames and passwords. I've used it in a (nonpublic) site I developed and it was a bit of a hassle to get the authentication working properly, but if you can use one of the libraries out there, go for it!
HTTP authentication is standardized but something about it disturbs me. I dunno what. Something about a separate dialog box popping out of the browser makes me suspicious.
p.s. BBC's Digital Planet had a radio program my local radio station aired yesterday (17 Feb 2009) that talked about OpenID. So I guess when the radio talks about it, it must be starting to go mainstream.
My advice: do not reinvent the wheel. Web authentication is a wheel if I ever saw one, and it's remarkably difficult to get all the subtle pitfalls handled correctly. Chances are you'd miss something and end up with effectively no security.
Either go with an OpenID solution, or look into the many auth libraries out there, and pick a thoroughly-tested one.
See also: The Definitive Guide To Website Authentication