I'd like use couchdb for a web application with external user authentication by a XMPP-Server (Openfire). How can I achieve that? Let's say we have thre users:
basicuser#mydomain.tld
advanceduser#mydomain.tld
moreadvanceduser#mydomain.tld
Now basicuser#mydomain.tld should be able to read all documents that are suited for basic users.
advanceduser#mydomain.tld should be able to read AND write all documents that are suited for basic users.
moreadvanceduser#mydomain.tld should be able to read all documents that are suited for basic and advanced users.
Is that possible?
following OpenFire's Database installation Guide, only relational Databases work directly with Open Fire:
MySQL
Oracle
Microsoft SQLServer
PostgreSQL
IBM DB2
HSQLDB
My first thought was to try and move the complete database to couchdb.
Anyways, you will need different groups for mapping the different types of users. As far as I know, read/write access in CouchDB cannot be granted or revoked for single documents, but for databases. So you will end up with 3 databases, each for one type of access level.
I am not sure if it is a good advice to hanlde document based authentication in CouchDB by "tagging" documents with authlevels.
So, I can think of different szenarios:
If your XMPP server ot the database
was able to verify credentials via
webservices, you could make use of
that in the login procedure in your
couchapp.
If there are Webservices to your Openfire backing database, you could use these to synchronize users with couchdb and map them to auth lvl groups. I think this is not a very good approach, as you will have to handle updated or deleted users as well and have another point to think about security as well. This could of course also be done by scripting on python or what ever language you prefer.
Use LDAP to provide auth. Does not work with CouchDB for now.
Maybe a good idea would be to make
use of Z-XMPP, strophe or
basically any js framework that
handles XMPP in some way? There you
could learn about XMPP
authentication and maybe use this to
verify auth credentials with XMPP. I also just learned that there is a book about "Professional XMPP Programming with JavaScript and jQuery".
Now, these are no complete solutions provided, but something to think about, and discuss it.
Oh, and there's another Thread here at StackOverflow.
Regards, Chris
Related
Over the years I have written many apps for myself and for customers using VB.NET, most of these were standalone apps which worked on workstations and servers and didn't involve much if anything to do with networking, client/server or a backend.
I want to evolve and learn more, and specifically am interested in creating a "backend" for some of my apps so that the data from the client app, whether it be error information or custom data for a client can be sent from the "client" to whatever is the best option for the "backend". I would then store the received data in a database I assume and then have ability to view it, and parse the data to show specific results etc
This is a new area to me but one I want to learn more about, so I am hoping that others who have this knowledge / experience can give me some pointers as to the best route to take etc, especially covering the points below and anything else you think I need to know but have missed
What to use for the "backend"? I prefer to have it in the cloud rather than having my own server, so do I use something like Azure? if so what? or do I sign up for hosting with a company which provided ASP and .NET Core hosting and create something there? if so what would I use?
What are the best methods for sending data from a to b - I notice most services I currently use for my apps e.g. for sending mail or error reports etc often use JSON? is that best option?
How do I send the data, any built in or suggested frameworks or API's to use to "post / send" information from my client to my backend / remote endpoint?
Hope this all make sense, please ask if not, all comments appreciated, as I say I want to use this both as a way to create / modernize some of my existing apps, but also as a learning exercise to learn areas I don't know and hopefully also make user of newer / evolving technologies and solutions.
Thanks
I am researching on the technologies available to build a social network website. The front-end portion has been decided, but I am still unsure about the back-end. The back-end will also be handled by an server running NodeJS. I was planning on using something like MongoDB, or even a combination of MongoDB and a relational database, but I do not know what the best practices are.
I stumbled upon an article that talked about using GraphQL with different types of database structures. The writer mentioned SQL, Redis and MongoDB for their user data, but I did not quite understand their sturcture, or if it would work for mine.
Basically I would like to have users to sign up to my page and add descriptions about themselves, have friends, join groups, upload media (pictures and videos), etc. A pretty basic social network setup, but ultimately the question narrows down to:
"What database structures are best for what?"
Should the SQL handle: userID, email, password
MongoDB: about, description, posts
Redis: cache for something like posts feed
And how would you handle media uploads? SQL, MongoDB? I have not found any useful articles that talk about using different database structures and most of the other StackOverflow questions feel outdated. They either favor one or another, but not a combination.
TL;DR: There aren't really any particular databases you "should use for GraphQL." Just use whatever is best suited for your data and requirements.
I'll give you a rough idea how we use it at work. We have an app that lets users upload songs and videos for us to distribute to digital streaming platforms, e.g. Spotify and such.
We use Postgres to handle all of the app's "transactional data." This is user account info, their song/video metadata, where to send the money, other stuff for the app, etc. All these data are a mere few-hundred MB.
Multimedia uploads go to AWS S3, and the location of each file is stored in Postgres.
The "analytical data," regarding how well each song did on each platform, e.g. number of streams and money made in each region, is stored in Google BigQuery. There is much, much more of these data and Google BigQuery is more equipped for this size.
Of course, the question of which data store one should use is highly case-dependent. GraphQL didn't really influence any of these decisions. The nice thing about GraphQL is that the resolvers let you pull data from anywhere and conglomerate it all into a single API response. By using GraphQL you should feel liberated to use a variety of databases, each well tailored to the type of data it handles.
Well, GraphQL as methodology has nothing related to dbs - it's about how to organize API level of application. It means you should configure graphql schema (tables or entities, own fields, ect.) and set up resolver to fill out response model.
In case if you don't want to do it - you can use solution from the box, like NReco.GraphQL
Like most people, we're pretty impressed with BigQuery. We're willing to put up with it being based on proprietary "Dremel" in exchange for not having to configure a ton of servers in our LAN, on EC2, or anywhere else.
The REST API is excellent, and we're incorporating that into our apps, but we still find ourselves using the BQ Browser interface as well. We'd like to incorporate something like a 'generic SQL window' into our app, without divulging that the backend is BQ or that data is stored in Google at all, for that matter. Does Google provide a way to use their BQ browser tool in a white-label manner?
Note also, that even extending access to the existing browser tool is problematic. It relies on user-accounts existing in one's own domain - something that can't be done, in our case, with a customer's email address. The REST interface solves this with service-level accounts, but that doesn't get you to the SQL window/browser tool.
If the folks at Google are listening (and I know that you are), consider the benefits of white-labeling the browser tool: I think you'd find a lot of software companies integrating it into their suites of products and, then, running circles around any Hadoop/CDH/EMR/Impala/Hive combination.
So, to summarize: How does a software developer import or emulate the BQ browser tool (with all it's autocompletes, query histories, etc..) in their own web-based app?
The initial version of the BigQuery web interface was considered just an 'example' UI that anyone could create themselves. It uses only the public BigQuery API to talk to BigQuery.
There are a couple of Google-internal things we've added since then, such as the current design of 'saved queries', and an auth shortcut so that users don't have to explicitly grant permission to the UI to access BigQuery data. But it is still mostly plain-ol-javascript talking to BigQuery via the REST API the same way anybody else does.
The javascript is obfuscated, however, but my understanding is that this is just for compression purposes so that it downloads more quickly.
The SQL highlighting is done by CodeMirror with special configuration for the BigQuery SQL variant.
I'll talk to the other members of the BigQuery team about open-sourcing the javascript code in the Web UI. It may be difficult to do at this point, but it doesn't hurt to have a conversation about it. I'll bring this up with the team and update this thread. The most likely answer will be "We'll think about it", but hopefully we can also think about it and start working on it too :-)
Let me know if that sounds like it would meet your needs. It might not solve the auth problems you mention, since your users likely won't have BigQuery accounts, but you may be able to solve that by proxying oauth2 access tokens.
I am looking into creating a login for my website. I am currently receiving free hosting from my college (UW Whitewater) server. I have learned HTML, CSS and JavaScript fairly well, but have not used any of these three languages a ton.
I would like to create a login for users to login to see their account information and use a web app that I will be creating in the future, but for now that doesn't matter.
I would like to know an overhead view of what I need to be able to have a login and keep account information for users.
Now I'm guessing I'm gonna need a database, and some kind of PHP or server-side language. Which language will be the best? As for the database is it possible to use an Access database? Also I dont know if UW Whitewater has mySQL that I can use or not? Is that possible? I would like to keep this free... college student here haha. I would also definitely be willing to learn a new language too.
Thanks for any replies in advanced!
If I were you, here's what I would do:
Decide what server-side language you want to use and which database you want to use based on whatever is available at your college. Although it is possible that they support many languages, if you ask the local IT administrators they will probably be able to suggest the best one for you, or they might even have a standard that they mandate.
Once you know which server-side language and database, do a web search on how to create a simple user login page with that language and database. There are tons out there.
If you run into any specific problems with your chosen solution, this would be the place to post them. But your question at the moment is probably a bit too broad.
I'm starting a new project with Symfony 2 and I have to create and manage some users with many personnal informations.
I must decide to chose a way to manage us and i wish receive some advice for chose Symfony 2 basic implementation or FOSUserBundle for example.
Use FOSUserBundle. It's easy to install and configure.
At the most basic level, it lets you easily handle user storage and authentication through the database. It requires that your user entity conform to some of its 'standards', but after that you're free to write your user entity how you see fit.
AFAIK, it's also the most popular user management solution for Symfony2 right now, so you should be able to easily find resources/information for it online.