It appears that the best PAM module for ruby is "rpam". However this module hard codes the service name "rpam" when calling pam_start which seems to be denied by default on at least RHEL. I can get rpam to work by hacking the source to change the hardcoded service name to something present in /etc/pam.d.
Do people normally reconfigure PAM to make use of rpam? Is there a better PAM module out there? (It needs to work with Ruby 1.9.) Is there something obvious I'm missing?
Having researched more, it looks to me like people normally add an rpam file to /etc/pam.d/.
You have to provide a PAM config file in /etc/pam.d. An easy way would be to copy the existing login config.
# root required
cp /etc/pam.d/login /etc/pam.d/rpam
You can also use rpam2 gem, which lets you specify the PAM service in the function call
# 'login' is the used pam service; if nil 'rpam' is used
Rpam2.auth('login', user, password)
Sorry for being 12 years late.
Related
I'm writing a custom provider and I'm only going to use it in the context of the module it's attached to. The module will already define things for the resource which I need to act on (e.g. username, password, IP Address). What I'm trying to do is access a variable in scope in the puppet manifest from the custom provider.
Is this possible?
init.pp:
class mymodule(
$username = 'admin',
-- snip --
}
provider.rb:
class Puppet::Provider::MyProvider < Puppet::Provider
def self.configure
#can I get to $mymodule::username here?
Some context:
I'm writing a set of types that will configure a server via an API. I want to have a type like:
mymodule_mail_settings { 'current':
server => 'mail.server.com'
mailuser => 'mail'
}
What I'm trying to avoid is having to pass the username/password/ip to access the server's API passed into all of these different types.
The variables are only meaningful in the context of evaluating the manifest code and creating a catalog. They don't become part of the catalog. This is why your type/provider code cannot work with them directly.
To avoid passing redundant info to lots of resources that share it, you can use some "clever" tricks. In a patch I wrote some time ago, I added this kind of meta-information to Puppet's resources type. You cannot do this in a module, but you can add your own meta-type to carry such hints.
I'm using the Check package to validate parameters passed to Meteor methods. And I'm using Audit argument checks to enforce this.
However, I've added another package, Meteor Tags and when I try to use methods from the Tags package, I get a server error "Exception while invoking method '/patterns/addTag' Error: Did not check() all arguments during call to '/patterns/addTag'".
I think I understand why this error happens - the method in the Tags package doesn't check its inputs, so Audit Argument Checks generates an error. But I can't find any way around this, apart from 1) don't enforce checking, or 2) hack the Tags package methods so they use check. Neither of these seems like a great option - checking server parameters is a good idea, and hacking a package is not very maintainable.
Does anybody know if there is any smart way to use 'Audit argument checks' with packages that provide new server methods? I have looked at the Check documents, and searched online, but I haven't found an answer.
I hope this question makes sense.
Using audit-argument-checks is like saying: "I want to be serious about the security of the methods in my app." It's global to all methods in your app's codebase, including the methods from your installed packages.
There is no way to specify which parts of the app get checked, as that would be the equivalent of saying: "I want to be serious about the security of the methods I've written, but I don't care about the security holes created by some pacakges" (which doesn't make a lot of sense).
Note to package authors
Check your method arguments. It's not hard, and it prevents this situation from happening. Frankly, a package without this basic security really shouldn't be installed in the first place.
What you should do
Unless you have a throwaway app, I wouldn't recommend removing audit-argument-checks. Instead I'd do the following (assuming the package really has something of value):
Open an issue on github and let the maintainer know what's up.
Fork the code, and add the required checks. Keep this version as a local package.
Submit a pull request for the changes.
If all goes well, your PR will be accepted and everyone can benefit from the change. In the worst case, you'll still have a local copy that you can use in your app.
I currently build web app which is using external MongoDb via Mongolabs.
The api is based on personal key using in urls. As docs says e.g.:
Here’s an example of a complete Resource URL:
https://api.mongolab.com/api/1/databases?apiKey=**2E81PUmPFI84t7UIc_5YdldAp1ruUPKye**
So the question is how to securely store such api key 2E81PUmPFI84t7UIc_5YdldAp1ruUPKye
Reading Django docs about Cross Site Request Forgery but stil do not understand where the key is recorded.
There are two ways to do this.
One way is to have a local_settings.py file that's imported in the main settings.py file and put into .gitignore so it's not in git. Some people however think this isn't good practice, because it might tempt to put complex things in there that aren't in VCS, so people effectively have different environments. I however am fine with it.
try:
from local_settings import *
except ImportError:
pass # No local_settings file
The other way (recommended by dislikers of the first way) is by setting it via environment variables, and reading these in settings.py.
MONGO_API_KEY = os.environ['MONGO_API_KEY']
You'd then have to pass the environment variable somehow though. E.g. via uwsgi's environ setting, or by setting it in your bash with export, or via another way.
I would load it in the settings file from an environment variable. Have a look at the Django Settings
One alternative is to use the library django-fernet-fields that uses the library cryptography.
The usage is very simple. In your model you need to add a new field:
from django.db import models
from fernet_fields import EncryptedTextField
class MyModel(models.Model):
apikey = EncryptedTextField()
By default, the field is going to be encrypted using the SECRET_KEY from your settings. So if you change it or lose it, you will not be able to access your data.
For better security, you can save your SECRET_KEY as an environment variable, and then pass it to the settings file.
import os
SECRET_KEY = os.environ.get('APP_SECRET_KEY', 'unsafe-secret-key')
django-fernet-fields
Quick answer:
Store in .env
Read in settings.py
I am somewhat new to Ruby, especially the more advanced concepts like modules and mixins, so I might be using module totally out of context..
I am currently writing an internal test framework using Capybara and I am trying to figure out the best/easiest way of handling configuration data. I file a file called config.rb and within it I want to store configuration settings per environment. For example:
module QAConfiguration
config data goes here
end
module DevConfiguration
config data goes here
end
The simplest example of configuration data is usernames and password. QA and Dev of course use different users. I am thinking of two different ways of going about this but I want to make sure I am following at least a decent practice and not going into the weeds.
module QAConfiguration
USERNAME = 'test'
PASSWORD = 'test'
end
or..
module QAConfiguration
def username
'test'
end
end
And so on. Which is the best way of approaching this?
A module probably isn't the best way to implement this. Generally when testing (I use rspec) we use helper files that contain reusable code.
Object attributes like usernames and passwords are usually handled by Factories. A great gem for factories is FactoryGirl.
A common way to store configuration in ruby/rails is in a yaml file. You could for example create a file called config/test_conf.yml with yaml format:
username: 'your_user'
password: 'somepass'
Then where you need the config data:
config = YAML.load(File.read("#{Rails.root}/config/test_conf.yml"))
puts config['username']
And finally, you will usually only put a test_config.yml.example on git/svn and in your app setup readme note that they need to cp config/test_config.yml.example config/test_config.yml and edit the file.
I'm working on a Web Service project to provide data to a partner. Our app is really light weight and has only a handful of APIs. Because of time constraint and in-house pre-existing knowledge we went the Spring MVC / Spring Security path to serve those restful APIs.
At any rate this is a B2B project where we are expecting only that partner to hit our servers. So it seems a little over kill to modify are very small db schemas to add tables that would contain only 1 user access record for that partner...
Heard someone say though that it's possible to use an encrypted file, or at least a file where the password information is encrypted, instead of the database to hold the Spring Security user access information... Is that true? If it is can anyone point me to some references? I couldn't find anything relevant on Google at first glance... :(
Thanks.
http://www.mularien.com/blog/2008/07/07/5-minute-guide-to-spring-security/
See the '' under the authentication-provider; this allows you to use encrypted passwords (use sha). If you only have a single user and you wanted the information in an external file, then you could use a property file configuration placeholder to simply specify
${user.1.id} ${user.1.passwordenc},etc... kinda hacky, but it would work.
It's VERY possible. In fact, you can do it without coding; it's pretty simple to include the credentials directly in the XML defining the Spring Security stuff. You usually see this in examples, followed by warnings to "DON'T DO IT LIKE THIS!"
If in-house security is no big deal and you're not worried that your developers can see your password (as if they needed it, heh!) and no one else is likely to access your configuration files, then this is a quick and easy yet workable solution.
I'm going to post this, but I'm off to go dig in the Spring Security documentation for the example I was talking about I'll be back!
Update
Trever Schick was a bit faster with the example. I had a different example in mind but his code shows exactly what I was talking about. You define your security provider in the XML and provide user ID/password right there. There are a number of utilities available on the 'net for you to MD5 or SHA encode your password for you so you can cut and paste it into the file.
You need to implement a new org.springframework.security.core.userdetails.UserDetailsService that reads the user's information (username, password, enabled flag, and authorities) from a file. I don't know if someone already implemented it.