I am using nodejs in the backend. Users can share photos on the site. There is role-based authorization and authorized roles can also share articles and so on. There are also content management panels for admins. I am using mysql as database. I am planning to install Nginx on the server I will buy. For a start, there is a user base that will get a maximum of 200 clicks per day. What would be the most suitable server features for this site?
This kind of opinion base questions are better to be asked on Quora, StackExchange, as was told in this SO discussion.
Anyways, 200 clicks per day is too few, you may even find a free server to upload it, take a look at AWS free plans, Heroku.
In case you will host in a machine, you may need to use forever library to runs your nodejs script continuously.
Related
I am working on a news media website, and I am looking to add feature to allow users to register, login and make comments.
For example (New York Times login/register screen)
May I know what options are available, what are the common approaches publishers would choose ?
So far I have been looking at:
AWS Cognito: Allows to create own user directory, and authenticate.
Disquss SSO: also implemented commenting.
In house development: Code a new microservice to manage user directory and store/serve comments, alternatively using AWS Lambda. I am very keen to go down that path, example, but this might costs a lot to develop + maintain.
User data security is my top consideration, I would prefer to use a separate system to store user data. Either a robust third party service or complete in house development of a new system.
Any suggestions?
Thank you.
These are web-standards for single sign on:
OpenID
OpenID Connect
Companies like Google and Facebook provide authentication using Google-/Facebook-accounts. As far as I know, Google uses OpenID Connect which is based on OAuth. However, I don't know if you don't have to store user data any more at all when using this.
I believe it's worth checking again if authentication and commenting should be combined, especially when using a third-party-solution. It makes it harder to change one of the two.
This could give you some more ideas: https://en.m.wikipedia.org/wiki/List_of_single_sign-on_implementations.
I have a website which will be used to show dashboards created in Tableau Desktop and published in Tableau Online.
I wanted to use Tableau Javascript API to access the dashboard to show it to users, but I don't want my web users to login to Tableau online.
My question is simply that "Can Tableau Javascript API be used to login to Tableau Online in the background and then fetch dashboards/views from it..?"
Based on my reading of the authentication documentation, there are three options:
Tableau Public requires no authentication for users to see visualizations. Tradeoffs: visualizations are static and public, and your storage space is limited. Ref: this forum discussion.
Tableau Online requires user login.
Tableau Server requires
user login, unless you configure it to say that requests from your
web server are always from trusted users. (See Trusted Authentication.) But even then, I think the license agreement requires that they be licensed users. You can license Tableau Server by # of cores instead of # of users though, in which case Tableau Server allows you to set up a Guest user that can access views anonymously.
So the short answer to your question appears to be no, not with Tableau Online. You have other options, but you either have to live with Public's limits or you'll need your own server, running Tableau Server. Even then you'd need to pay for each user to be licensed to access the product, unless you purchase a license based on # of cores, not # of users.
I'm quite new to Cloud Storage solutions, and I'm currently researching options to upgrade our current solution (we currently just upload on a SVN server).
What I have is a native application running on client computers, which will upload data to the Cloud Storage. Afterwards, client should be able to download and browse their data (source is not set in stone, could be a website or from other applications). They should not be able to access other user's data.
I'm not sure how I'm supposed to proceed. As far as I understand, the native application will upload using a Native Application Credential, using JSON.
Do I need multiple credentials to track multiple users? That seems wrong to me. Besides when they come back as 'users' through the web interface, they wouldn't be using that authentification, would they?
Do I need to change the ACL of the uploaded files afterwards?
Should I just not give write/read access to any particular users and handle read requests through Signed URLs, dealing with permission details by myself using something else on the side? (not forcing a Google Account is probably a requirement)
Sorry if this is too many questions, and thanks!
Benjamin
The "individual credentials per instance of an app" question has come up before, and unfortunately there's not a great answer. If you want every user to have different permissions, you need every user to be associated with a different account.
Like you point out, the best current answer, other than requiring users to have Google accounts, is to have a centralized service that vends signed URLs to the end applications. That service would be the only owner of all of the objects and would give out permission to read or upload as needed.
I have tried Google with queries similar to the title of this question, but haven't found anything useful.
Background: I am building a web app and would like to add a user authentication level to it. I cannot imagine anything worse than building a user authentication system from the ground up, so I want a quick solution.
I'm looking for open source software I can host on my server that provides an auth layer I can connect to, with multiple user accounts
Criteria:
I want to host the software on my own server
Provide a log in screen that works with multiple sign in strategies - twitter, facebook, vanilla email, etc.
Persists users to a database (preferably postgres) and persists session data
Preferably lets me store a minimal amount of data per user, like key value store
Has a client-side (Javascript) API, like Facebook's JS, so I can use this auth service on multiple sites. Namely, I want to use it on localhost or my own file system (when allowing file cookies). Client side JS API exposes methods like log in / log out
Has a server side API (such as exposes local RESTful endpoints) so that when I do build out my server side app for other data storage outside of the user, my app can query the auth service for log in status.
I want to run this stack completely independently of my own app - in fact I want to run this auth service and purely communicate to it from my local dev environment without building any server side app of my own.
I have used Firebase and they do many of the things that I want, including log in strategies and the client / server side APIs, but I want to be able to host my own version of this.
I can't imagine anyone takes pleasure out of building user authentication of any kind, so I'm surprised I haven't found anything in research.
I also know this is an open-ended question, but as far as I can tell I haven't found anything satisfying my requirements.
I like Devise (https://github.com/plataformatec/devise), which is for Rails. It has an active community with a boatloads of plugins available that can fulfill many of your requirements.
I didn't see a language specified; most languages and frameworks have their own implementations. Can you provide more information?
Example: I use the Flask framework on python. In addition, I use the Authomatic library which provides Oauth access for twitter, google, facebook, etc.
What I was looking for is something called a Single Sign On solution. According to this list there is nothing currently that meets my criteria.
Instead I have chosen to just run a local webserver and implement a regular auth flow.
Jeff Atwood argues that we should stop asking users to register on our websites because we should rather use their "internet driver's license -- that is, [their] existing Twitter, Facebook, Google, or OpenID credentials" for authenticating them.
While I am beginning to think that he may be right, I could not yet decide and I am looking for arguments against letting foreign sites gain control over personal web pages.
Do you see any dangers of authenticating users like this?
if you want a more in depth response based from someone who has dealt with this technology before, you should listen to the recent .NET Rocks with Rob Connery which was precisely about this topic.
http://www.dotnetrocks.com/default.aspx?showNum=626
After listening to it I decided to NOT use OpenID on my site.
Here is the link to Rob's blog post on the subject:
http://blog.wekeroad.com/thoughts/open-id-is-a-party-that-happened
Here are a number of reasons why not, although each comes with caveats:
If you only authenticate with one external service, anyone who doesn't use that service cannot use yours.
If your external authentication service goes down, users won't be able to use yours until theirs comes back up; similarly, slowdowns in their authentication server will also affect you.
Requiring users to authenticate with another service requires them to accept that service's EULA, which may be a turnoff for some; similarly, it ties you morally to whatever decisions your authenticating service makes. In particular it can make you appear to be a satellite, spinoff or affiliate of the auth site, since users have to see their logo every time they try to use your service.
The external auth domain gets a perfect snapshot of your viewership, giving them a lot of insight into what your company is doing. Since their analytical tools and staff are generally top-notch, they may conceivably know more about your user base than you do.
The major way to avoid this problem is to allow people to use the service of their choice, instead of a single service. If you are limited to developing one, for development time constraints, using OpenID is the best bet because many other authentication domains also qualify as OpenIDs, and therefore ameliorates most of the above problems.
I think using IDs from any of these big names are ok as long as you don't provide service that needs an endpoint like email, IM etc.
However, OpenID is just not trust-worthy. If you have any doubts, try this OpenID
http://opennoid.appspot.com/anyid
This is a disposable ID that doesn't require a password to login.