I'm looking for the simplest way to register and authenticate a user with the express library for node.js. I would like to store the users in a redis db.
I would prefer to use only express and not an additional library.
Also, once a user is authenticated. How should I carry out storing information pertinent to only that user? Perhaps the user's login would be the key in the redis db, and the value would be an array of other information? Or is that not a good solution?
I'm not familiar with authentication, but have some familiarity with node, express and redis so it hopefully won't be too much of a problem.
Any suggestions are welcome!
Check out EveryAuth. From what I've seen, it provides the most comprehensive solution, including support for passwords, OpenID, OAuth, LDAP, and so forth. You can use it and allow your users to login with a password or with many different online services, including twitter, facebook, linkedin, etc.
https://github.com/bnoguchi/everyauth
Here's a pretty decent video tutorial that integrates it with CouchDB:
http://nodetuts.com/tutorials/26-starting-with-everyauth.html
https://github.com/pgte/nodetuts_26
I'm not familiar with authentication, but have some familiarity with
node, express and redis so it hopefully won't be too much of a
problem.
If you really want store passwords inside your database, which I don't think you should do(see below), you could have a quick look at TJ's example to do authentication.
I always think it is a bad idea to store passwords inside your (own) database. Stackoverflow author Jeff Atwood does have a very interesting article about this named OpenID: Does The World Really Need Yet Another Username and Password?. I would advise you to use systems like OpenID(facebook-connect, etc) just like stackoverflow.com is doing. A good openid library is available, which is very easy to use.
connect-auth is a good choice for third party auth.
If you are planning to write your own, see this thread for an example
Related
Getting a bit lost in the diverse documentation endpoints (here, here, to name a few…)
This one is pretty usable for a given account by providing a json key as an environment variable.
The thing is, I just don't see how commands can be run on the behalf of a user authenticated via oauth — practically speaking, where do you specify the oauth user token ?
Thanks for sharing this insight
Best
google-cloud-ruby (which you linked in your question) is designed to provide access via service account credentials, as you noted. For help with "lower-level" access in which you managing your own OAuth tokens, you might consider google-auth-library-ruby. However, if you can use a service account instead of a user account to use the higher-level access provided by google-cloud-ruby, I believe it's probably the best approach, as recommended in Google Cloud Storage Authentication:
Due to the complexity of managing and refreshing access tokens and the security risk when dealing directly with cryptographic applications, we strongly encourage you to use a verified client library.
Say that I have two or more completely separate web applications. The might even be running on a different server and use different language & framework.
What I need to do is to share state, or at least authentication. For example if the user logs in on one of the websites and goes to another one, he will be able to authenticate using his credentials from the first website.
For example, if I have one website running e-commerce and another one is a blog, I want all the e-commerce users be able to comment on the blog with the information from their profile.
What is the best way to do this? Is it even a good idea?
The only solution that comes to my mind is abstracting away the profiles and authentication and create some kind of global profile and then use that on both of those websites. But that seems like a really complex solution considering what I need to achieve.
OpenID seems like a good way.
I am looking for the best practice for storing user credentials in a windows 7 phone app. I am writing an app for a web service that requires authentication. Thankfully it is only basic authentication at this point. What is the best way to store those credentials?
The best way to store credentials in your case would be encrypting them and storing in the application-specific isolated storage - basically, it cannot be accessed by any other application, so that gives another protection layer.
In terms of security, the best practice would be to avoid storing user credentials if possible. MSDN states:
Applications often ask users to
provide a username and password that
is used as credentials to authenticate
the user with a web service or
website, yet if they do so each time
the application is run, users can
become annoyed.
It is strongly recommended that your
application prompt for usernames and
passwords each time your application
needs them from the user; if you
attempt to save the credentials on the
phone you risk exposure of those
credentials to a malicious application
if the Windows Phone is lost or
stolen.
Actually, in the data encryption tutorial mentioned in the other answer, Rob Tiffany makes a similar disclaimer:
The OS Does Not include framework
support for storing your passwords and
salt values securely nor does it come
with any kind of built-in key
management. This means the only way
to ensure your encrypted data is
actually secure is to never store
your password, salt value or keys on
the phone.
...
If you see an app in the Windows
Phone Marketplace that allows you to
cache your credentials or keys locally
for convenience, be aware that these
are Not Secure solutions because
everything a hacker needs to get at
your data is right there in the code
or in Isolated Storage.
Encryption is good for raising the bar, but this would not really protect the credentials from a knowledegable hacker. Usability sometimes trumps security, but you should take this decision knowing that encryption will not solve the core issue in this case (and maybe let the user be aware of this risk).
A good explanation by Rob Tiffany of how to encrypt your data in isolated storage can be found here:
Don’t forget to Encrypt your Windows Phone 7 Data
I haven't tried out the code myself, so can't vouch for it's correctness (sorry Rob :-) - should serve as a good starting point though, I would imagine.
I also second Dennis' point about application-specific isolated storage giving you an additional/basic layer of protection in addition to encryption, as theoretically at least, other applications cannot access your applications isolated store.
You should use the ProtectedData class to store securely various bits of confidential information.
Learn more at How to: Encrypt Data in a Windows Phone Application
We are working on a service that will have website access for stats and other tasks, but the majority of use will be through a client gem and rake tasks. What is the best way to handle authentication for both pieces.
It looks like fiveruns_tuneup, getexceptional, New Relic and others have websites with username and pass, but use API keys stored in ./config/serviceName.yml Any reasons it is better to have API keys opposed to user/pass in the config (do they use keys because often the key is checked into SCM and used across the project, where ours would not be checked in and would be a per user setting)
GitHub has you put your public key on the github servers and uses that, but I think git supports public/private key by default.
Would it be preferred to keep a ./config/serviceName.yml or since we have to create a subdirectory with other information have ./serviceName/config.yml? (does the per user, not stored in SCM mean it is better to keep it all in one excluded directory?)
Just looking for some thoughts and ideas on best practices before starting implementation.
I recommend that you use username/password combos for website accounts, and API keys for any web services. Here are the advantages of this technique:
By linking API keys to an account, you could have many API keys for the same user. Perhaps this could be used for many remote web servers that consume this data service, or to perform unique tracking.
Attaching API keys to an account also lets you keep the user's username and password uncompromised since an API key will not contain them. Many users use the same username and password on many services, so you are helping to protect them.
You could limit access to portions of functionality for each API key, but give their username access to everything their account should have access to. Additionally, you can even give them the ability to limit how much access an API key might have.
Most of the major services (Yahoo! API, Flickr, Google API, etc) use accounts with a username and password to login to the web account, and API keys for integration points.
Never use user/pass when you can help it. The security issues are horrible. If the user/pass leaks out, you have to change your password or they get access to your whole account.
API keys are better because they're easier to change and can be limited to only the part you need access to with the APIs (ie, if someone has your password they can change your password. They can't if they just have an API key).
Different API key per client or secure token exchange (such as OAuth) is the best solution if you'll have more than just your client on the API.
The github approach is bootstrapping on top of existing git practices, however it's not a bad idea since presumably each user will have their own private key to match a published public one in the central authority. Since key-agent's already furnish a means of safe authentication this seems like a very safe approach. Public/private keys are a well thought out authentication scheme, which has unfortunately been reinvented many times to limited success.
The problem with the API key is that anyone who gets a copy of the API key can do whatever that authorizes. Storing the API key somewhere in the project begs the users to share a key. If you are associating public keys with a user, it is possible to grant rights to the client on a per user basis, and a proper key-agent approach suggests that those will not be stored in an SCM anywhere.
I'm not sure I follow what the distinction between config/serviceName.yml, or serviceName/config.yml is. It doesn't seem as if it would be pertinent if you have public/private keys as an authentication method for the client.
The company where I work for (1800+ Employees) is looking to enhance the personal relationships between its employees, allow a better collaboration and communication between departments and make it easier for the HR department to identify skills, experience and interests among the personnel (ex: we have some colleagues with deep knowledge of SAP modules and products, but during concrete projects it results very difficult to identify them and integrate them). Therefore, they want to implement a social network for our intranet.
We are just looking for the basic features such as profiles, discussion boards and so on, so nothing fancy. I proposed Community Server but my boss said .Net and java are no-gos. He wants LAMP and is not interested in a web solution like Ning, because of privacy and security concerns. It does not matter if it is Open-Source or commercial software. But it should allow a complete layout customization and must also have access from the outside world.
So my question would be, is there something like Community Server running on a LAMP stack?
Thank you very much!
UPDATE: We already have a Facebook page and a group. But my boss wants some features not included in Facebook such as a tag cloud in each profile page displaying skills and relevant proyects; and a feature like the "neighborhoods" from Last.FM, where you can group people with similar skills and interests and there is also the confidentialy issue (discussions about projects, clients, etc). So, any ideas?
You should check out StatusNet. http://status.net/
It doesn't directly answer your question, but aren't you rather trying to reinvent the wheel?
Facebook has got Social Networking down and the likely hood is 95% of your 1800 employees already use it.
Why would you go to the effort of writing and supporting a product as well as asking your employees to update information about themselves in multiple places when you could just set up a Facebook Network.
The other point I would make is, why are you limiting yourself to one way of doing things right from the off. Perhaps a detailed analysis of which technologies best serve your purpose would be more appropriate.
I appreciate this doesn't answer you question, I just feel this is a good example of Corporations unwilling to embrace tools already out there, I suspect because they are scared of them.
I'm probably right in guess that you're company heavily monitors Facebook usage, which is why this also might be hard.
Try Open Atrium, a Drupal-based team server.
Some sort of facebook application would allow you to keep the data on a server that you manage, but still use facebook's existing features. Pretty certain that facebook uses PHP for its application framework.
I agree with MrEdmundo and would upvote him if I were registered. Dont fall victim to "It wasnt invented here" syndrome. I bet your boss is like "we need something like facebook".
If it makes you feel better... here is a little story:
I was trying to implement some sort of group chat so fellow employees could ask quick questions to eachother online without having to get up or if someone was on the phone, etc. However, the service I installed (some sort of jabber daemon, i forget which one) never really got used. The solution? Just install the facebook chat client because all the co-workers are already on facebook most the day anyways!
plus, the "screen name" is appropriate because it is our real names, not stuff like "Out Into Space", "theman", or "fly-mystikal-dj-69"
You might want to consider something like Drupal. It's technically a CMS, but it's extremely customizable, and there are a lot of modules available that provide social-networking-style features.
Use Office Messenger for communication. It's basically like MSN Messenger but run on the company's servers so they can monitor all traffic. To know who has expertise in what area, it can't be too hard to build your own simple CRUD application to record profiles of employees and have each profile tagged with key skills, that the employee has and build a search function to find the people with the skills you need at any given time.
You can create an application using the Facebook SDK (PHP, java or any other language) and moderate it so that only employees can use it. That way you can use the existing Facebook features and add the tag clouds and other stuff your boss wants.
I've not used it, but Dolphin might be worth downloading to try out.
elgg.org
LAMP easy to install and setup, looks like your requirements would all be easily satisfied by the official plugins that are available.
Another option: http://buddypress.org/