I have a rails app that I have deployed to AWS Elastic Beanstalk. The app uses devise to handle user authentication, and its set to be able to invite users.
My issue is that when I try to invite a user, I get the following error:
Net::SMTPFatalError (554 secureserver.net ESMTP No Relay Access Allowed From <my_eb_assigned_ip>
(I am hosting the domain on GoDaddy).
In development, the mailer functionality works fine; my smtp settings are set to (common to all environments):
ActionMailer::Base.delivery_method = :smtp
ActionMailer::Base.smtp_settings = {
:address => "smtpout.secureserver.net",
:port => 80,
:domain => "www.my_domain.com",
:authentication => :plain,
:user_name => "do-not-reply#my_domain.com",
:password => my_pass,
}
And in my production.rb config file:
config.action_mailer.default_url_options = { :host => 'aws_sb.elasticbeanstalk.com' }
Is there another setting I have to enable in Elasticbeanstalk to allow relay access? Or am I missing a production specific setting from my rails configuration?
I figured out it was the port value that I was setting....when I switched the port to 25, it works in production. However, for development, port 25 wasn't working; it would only work in dev when the port was 80.
So I ended up moving the entire smtp mailer settings into the environment specific settings (from the config/environment.rb file), and setting the production port to 25, and the development port to 80, and that appeared to make both environments work.
Edit: After another push, I was seeing the same issue, and none of the ports I tried were resolving the issue. So I ended up switching all my mail functionality to be sent through Amazon SES, and that appears to be functioning great so far.
I'm using Mandrill to build a feedback form for users on the website (they fill the form and send me an e-mail).
I want to test the e-mail functionality in development. I use unicorn as a server and my local address is 0.0.0:8080
However I get a 500 server error, Net::SMTPServerBusy : Relay Access Denied
I followed the Heroku instructions step by step.
Here is m application.rb configuration:
config.action_mailer.smtp_settings = {
:address => 'smtp.mandrillapp.com',
:port => '587',
:domain => 'heroku.com',
:user_name => ENV['MANDRILL_USERNAME'],
:password => ENV['MANDRILL_APIKEY']
}
ActionMailer::Base.delivery_method = :smtp
I followed the instructions on mandrill/heroku web page to set up.
I have a .env file set up with a MANDRILL_USERNAME and my MANDRILL_APIKEY
Here is my ActionMailer file:
class FeedbackMailer < ActionMailer::Base
default :from => ""
default :to => "xxx#stanford.edu"
default :subject => "feedback about xxx"
def send_feedback(message)
#debugger
#message = message
mail(:from => message[:sender_email])
end
end
Any help would be appreciated.
I can confirm e-mails get sent in production.
If all of your settings are working in production but not locally, there are a couple of possibilities:
How are you loading the variables from .env to ENV? It's possible the environment variables aren't getting loaded as expected locally. If you hard code the credentials locally, does it work?
You could be running in to an issue with the port or outbound SMTP traffic being blocked. Consider trying port 2525, as it may be less likely to be blocked by local ISPs. Port 465 with SSL enabled may also work even if your ISP is blocking other SMTP traffic
I want to set up Gitlab with our company's LDAP as a demo. But unfortunately I have to put in an admin password in gitlab.yml to make gitlab access the LDAP service. The problem actually is the administration, as they don't want to setup another account just for Gitlab. Is there any way to circumvent this without filling in my own password? Is there a way to make Gitlab establish the LDAP connection with only the provided user credentials?
Any ideas beside logging in as anonymous?
Already posted here.
I haven't tried it yet, but from the things I've build so far authenticating against LDAP and the informations from the config-file this user-account seems only to be needed when your LDAP does not support anonymous binding and searching.
So I would leave the two entries bind_dn and password commented out and try whether it works or not.
UPDATE
I've implemented LDAP-Autehntication in Gitlab and it's fairly easy.
In the gitlab.yml-file there is a section called ldap.
There you have to provide the informations to connect to your LDAP. It seems that all fields have to be given, there seems to be no fallback default! If you want to use anonymous binding for retrieval of the users DN supply an empty string for bind_dn and password. Commenting them out seems not to work! At least I got a 501 Error message.
More information can be found at https://github.com/patthoyts/gitlabhq/wiki/Setting-up-ldap-auth and (more outdated but still helpful) https://github.com/intridea/omniauth-ldap
I have patched gitlab to work this way and documented the process in https://foivos.zakkak.net/tutorials/gitlab_ldap_auth_without_querying_account/
I shamelessly copy the instructions here for self-completeness.
Note: This tutorial was last tested with gitlab 8.2 installed from source.
This tutorial aims to describe how to modify a Gitlab installation to
use the users credentials to authenticate with the LDAP server. By
default Gitlab relies on anonymous binding or a special querying user
to ask the LDAP server about the existence of a user before
authenticating her with her own credentials. For security reasons,
however, many administrators disable anonymous binding and forbid the
creation of special querying LDAP users.
In this tutorial we assume that we have a gitlab setup at
gitlab.example.com and an LDAP server running on ldap.example.com, and
users have a DN of the following form:
CN=username,OU=Users,OU=division,OU=department,DC=example,DC=com.
Patching
To make Gitlab work in such cases we need to partly modify its
authentication mechanism regarding LDAP.
First, we replace the omniauth-ldap module with this derivation. To
achieve this we apply the following patch to gitlab/Gemfile:
diff --git a/Gemfile b/Gemfile
index 1171eeb..f25bc60 100644
--- a/Gemfile
+++ b/Gemfile
## -44,4 +44,5 ## gem 'gitlab-grack', '~> 2.0.2', require: 'grack'
# LDAP Auth
# GitLab fork with several improvements to original library. For full list of changes
# see https://github.com/intridea/omniauth-ldap/compare/master...gitlabhq:master
-gem 'gitlab_omniauth-ldap', '1.2.1', require: "omniauth-ldap"
+#gem 'gitlab_omniauth-ldap', '1.2.1', require: "omniauth-ldap"
+gem 'gitlab_omniauth-ldap', :git => 'https://github.com/zakkak/omniauth-ldap.git', require: 'net-ldap', require: "omniauth-ldap"
Now, we need to perform the following actions:
sudo -u git -H bundle install --without development test mysql --path vendor/bundle --no-deployment
sudo -u git -H bundle install --deployment --without development test mysql aws
These commands will fetch the modified omniauth-ldap module in
gitlab/vendor/bundle/ruby/2.x.x/bundler/gems. Now that the module is
fetched, we need to modify it to use the DN our LDAP server expects. We
achieve this by patching lib/omniauth/strategies/ldap.rb in
gitlab/vendor/bundle/ruby/2.x.x/bundler/gems/omniauth-ldap with:
diff --git a/lib/omniauth/strategies/ldap.rb b/lib/omniauth/strategies/ldap.rb
index 9ea62b4..da5e648 100644
--- a/lib/omniauth/strategies/ldap.rb
+++ b/lib/omniauth/strategies/ldap.rb
## -39,7 +39,7 ## module OmniAuth
return fail!(:missing_credentials) if missing_credentials?
# The HACK! FIXME: do it in a more generic/configurable way
- #options[:bind_dn] = "CN=#{request['username']},OU=Test,DC=my,DC=example,DC=com"
+ #options[:bind_dn] = "CN=#{request['username']},OU=Users,OU=division,OU=department,DC=example,DC=com"
#options[:password] = request['password']
#adaptor = OmniAuth::LDAP::Adaptor.new #options
With this module, gitlab uses the user's credentials to bind to the LDAP
server and query it, as well as, to authenticate the user herself.
This however will only work as long as the users do not use ssh-keys to
authenticate with Gitlab. When authenticating through an ssh-key, by
default Gitlab queries the LDAP server to find out whether the
corresponding user is (still) a valid user or not. At this point, we
cannot use the user credentials to query the LDAP server, since the user
did not provide them to us. As a result we disable this mechanism,
essentially allowing users with registered ssh-keys but removed from the
LDAP server to still use our Gitlab setup. To prevent such users from
being able to still use your Gitlab setup, you will have to manually
delete their ssh-keys from any accounts in your setup.
To disable this mechanism we patch gitlab/lib/gitlab/ldap/access.rb
with:
diff --git a/lib/gitlab/ldap/access.rb b/lib/gitlab/ldap/access.rb
index 16ff03c..9ebaeb6 100644
--- a/lib/gitlab/ldap/access.rb
+++ b/lib/gitlab/ldap/access.rb
## -14,15 +14,16 ## module Gitlab
end
def self.allowed?(user)
- self.open(user) do |access|
- if access.allowed?
- user.last_credential_check_at = Time.now
- user.save
- true
- else
- false
- end
- end
+ true
+ # self.open(user) do |access|
+ # if access.allowed?
+ # user.last_credential_check_at = Time.now
+ # user.save
+ # true
+ # else
+ # false
+ # end
+ # end
end
def initialize(user, adapter=nil)
## -32,20 +33,21 ## module Gitlab
end
def allowed?
- if Gitlab::LDAP::Person.find_by_dn(user.ldap_identity.extern_uid, adapter)
- return true unless ldap_config.active_directory
+ true
+ # if Gitlab::LDAP::Person.find_by_dn(user.ldap_identity.extern_uid, adapter)
+ # return true unless ldap_config.active_directory
- # Block user in GitLab if he/she was blocked in AD
- if Gitlab::LDAP::Person.disabled_via_active_directory?(user.ldap_identity.extern_uid, adapter)
- user.block unless user.blocked?
- false
- else
- user.activate if user.blocked? && !ldap_config.block_auto_created_users
- true
- end
- else
- false
- end
+ # # Block user in GitLab if he/she was blocked in AD
+ # if Gitlab::LDAP::Person.disabled_via_active_directory?(user.ldap_identity.extern_uid, adapter)
+ # user.block unless user.blocked?
+ # false
+ # else
+ # user.activate if user.blocked? && !ldap_config.block_auto_created_users
+ # true
+ # end
+ # else
+ # false
+ # end
rescue
false
end
Configuration
In gitlab.yml use something like the following (modify to your needs):
#
# 2. Auth settings
# ==========================
## LDAP settings
# You can inspect a sample of the LDAP users with login access by running:
# bundle exec rake gitlab:ldap:check RAILS_ENV=production
ldap:
enabled: true
servers:
##########################################################################
#
# Since GitLab 7.4, LDAP servers get ID's (below the ID is 'main'). GitLab
# Enterprise Edition now supports connecting to multiple LDAP servers.
#
# If you are updating from the old (pre-7.4) syntax, you MUST give your
# old server the ID 'main'.
#
##########################################################################
main: # 'main' is the GitLab 'provider ID' of this LDAP server
## label
#
# A human-friendly name for your LDAP server. It is OK to change the label later,
# for instance if you find out it is too large to fit on the web page.
#
# Example: 'Paris' or 'Acme, Ltd.'
label: 'LDAP_EXAMPLE_COM'
host: ldap.example.com
port: 636
uid: 'sAMAccountName'
method: 'ssl' # "tls" or "ssl" or "plain"
bind_dn: ''
password: ''
# This setting specifies if LDAP server is Active Directory LDAP server.
# For non AD servers it skips the AD specific queries.
# If your LDAP server is not AD, set this to false.
active_directory: true
# If allow_username_or_email_login is enabled, GitLab will ignore everything
# after the first '#' in the LDAP username submitted by the user on login.
#
# Example:
# - the user enters 'jane.doe#example.com' and 'p#ssw0rd' as LDAP credentials;
# - GitLab queries the LDAP server with 'jane.doe' and 'p#ssw0rd'.
#
# If you are using "uid: 'userPrincipalName'" on ActiveDirectory you need to
# disable this setting, because the userPrincipalName contains an '#'.
allow_username_or_email_login: false
# To maintain tight control over the number of active users on your GitLab installation,
# enable this setting to keep new users blocked until they have been cleared by the admin
# (default: false).
block_auto_created_users: false
# Base where we can search for users
#
# Ex. ou=People,dc=gitlab,dc=example
#
base: 'OU=Users,OU=division,OU=department,DC=example,DC=com'
# Filter LDAP users
#
# Format: RFC 4515 http://tools.ietf.org/search/rfc4515
# Ex. (employeeType=developer)
#
# Note: GitLab does not support omniauth-ldap's custom filter syntax.
#
user_filter: '(&(objectclass=user)(objectclass=person))'
GitLab uses omniauth to manage multiple login sources (including LDAP).
So if you can somehow extend omniauth in order to manage the LDAP connection differently, you could fetch the password from a different source.
That would allow you to avoid keeping said password in the ldap section of the gitlab.yml config file.
I am trying to upload data to amazon s3 bucket.
I am using aws-s3 gem for this purpose.
I am giving right access key and secure key but still not able to execute S3Object.store/Bucket calls, though the connection is established. They return with error "AWS::S3::SignatureDoesNotMatch: The request signature we calculated does not match the signature you provided. Check your key and signing method."
Interestingly I am running another rails app with paperclip plugin to upload images to S3, and that is working like a charm! with same access key and secure key.
I have tried referencing some links mentioning same problem but to no luck.
[ https://forums.aws.amazon.com/thread.jspa?threadID=16020&tstart=0 ]
Any pointers/help/suggestions would be great. :)
I just got this problem because I did not supply the correct region in the request.
I am using fog and Carrierwave as per the railscast here and I had to configure the region in the config/initializer for Carrierwave
CarrierWave.configure do |config|
config.fog_credentials = {
provider: 'AWS', # required
aws_access_key_id: '[redacted]', # required unless using use_iam_profile
aws_secret_access_key: '[redacted]', # required unless using use_iam_profile
# use_iam_profile: false, # optional, defaults to false
region: 'eu-central-1', # optional, defaults to 'us-east-1'
# host: 's3.example.com', # optional, defaults to nil
# endpoint: 'https://s3.example.com:8080' # optional, defaults to nil
}
config.fog_directory = 'xxx' # required
# config.fog_public = false # optional, defaults to true
# config.fog_attributes = { cache_control: "public, max-age=#{365.days.to_i}" } # optional, defaults to {}
end
interestingly fog was redirected to the correct endpoint with the correct region by amazon, however, the redirected request got the failure on the authentication, maybe a problem with fog in such a situation. Fog did give a nice warning in the log
[fog][WARNING] fog: followed redirect to calm4-files.s3.amazonaws.com, connecting to the matching region will be more performant
but to be more accurate they should say not only more performant, but it will actually work as well
My goal is to deploy a simple rails application on a windows server using the glassfish gem.
I have no trouble getting the glassfish gem to work with regular http, however I now need to add SSL security and I cannot find any links on how to enable https in the glassfish gem.
Has anyone succeeded in setting up the glassfish gem to support SSL?
Are there any other ways to serve a rails application over SSL on windows without any additional software installation (e.g. IIS, Glassfish, jBoss)?
I use jetty-rails gem and I coded SSL support in it.
If you choose to use jetty-rails as well you can follow these instructions to add SSL.
Make sure you use jetty-rails version 0.6 as current 0.8.1 is buggy.
I'm sure that GlassFish too can be made to use SSL in a similar way.
I chose Jetty as it seems faster (startup) smaller and easier to change the source.
jetty_rails-0.6/lib/jetty_rails/server.rb +32
if config[:ssl] and config[:ssl] == true
if config[:keystore] =~ /^\\/ # starts with slash => absolute dir
keystore = config[:keystore]
else # assume keystore is in cofig dir
keystore = #config[:base] + '/config/' + config[:keystore]
end
if not config[:truststore].nil? # have separate truststore
if config[:truststore] =~ /^\\/ # starts with slash => absolute dir
truststore = config[:truststore]
else # assume keystore is in cofig dir
truststore = #config[:base] + '/config/' + config[:truststore]
end
else # trustore == keystore
truststore = keystore
end
security_connector = Jetty::Security::SslSocketConnector.new
security_connector.set_acceptors(config[:acceptor_size])
security_connector.port = config[:port]
security_connector.confidential_port = config[:port]
security_connector.keystore = keystore
security_connector.password = config[:password]
security_connector.key_password = config[:key_password].nil? ? config[:password] : config[:key_password]
security_connector.truststore = truststore
security_connector.trust_password = config[:trust_pasword].nil? ? config[:password] : config[:trust_pasword]
#server.add_connector(security_connector)
else
connector = Jetty::SelectChannelConnector.new
connector.set_acceptors(config[:acceptor_size])
connector.port = config[:port]
connector.confidential_port = config[:security_port] if config[:security_port]
#server.add_connector(connector)
end
how to generate a certificate store (keystore.jks)
See here: http://docs.codehaus.org/display/JETTY/How+to+configure+SSL
RAILS_ROOT/config/jetty_rails.yml
# Config
:port: 3000
:jruby_min_runtimes: <%= config[:environment] == 'production' ? 3 : 1 %>
:jruby_max_runtimes: <%= config[:environment] == 'production' ? 6 : 2 %>
:thread_pool_max: 40
:thread_pool_min: 4
:acceptor_size: 10
# Security
:ssl: true
:keystore: keystore.jks
:password: your_pass
# :key_password: your_pass # if different
# :truststore: truststore.jks # if different
# :trust_pasword: your_pass # if different
start the server
jruby -S jetty_rails -c config/jetty_rails.yml