Changing username in config.yml

46 views
Skip to first unread message

Noora

unread,
Apr 28, 2014, 5:13:01 AM4/28/14
to rubycas...@googlegroups.com
Hi guys -

We've recently got rubycas-server setup, but our developer made an error. In the username_column, he listed our user's email column instead. So whenever someone changes their email, they can't login anymore. 

So I went into the config.yml file and changed it to the correct column and updated the database entries. I then restarted both apache and did a 'touch tmp/restart.txt' just to be on the safe side. However, rubycas is still pointing to the email column, according to our log file. Is there some cache I can clear out?

Matt Zukowski

unread,
Apr 30, 2014, 2:14:56 PM4/30/14
to rubycas...@googlegroups.com
Hm that seems strange. Did you end up getting this fixed, or are you still stuck? If so, can you paste us your config.yml file? (Just be sure to delete any sensitive parts like password and IPs)

Noora

unread,
May 3, 2014, 5:34:58 AM5/3/14
to rubycas...@googlegroups.com
Hey Matt -


Thanks for getting back to me. I am still having this issue; it's really stumped me. Here's the config.yml file, with all the sensitive data x'ed out:
____________
uri_path: /cas

database:
  adapter: mysql2 
  database: production
  username: xxxx
  password: xxxxxxxxxx
  host: localhost
  reconnect: true

authenticator:
  - class: CASServer::Authenticators::SQL
    database:
      adapter: mysql2 
      database: production
      username: xxxx 
      password: xxxxxxxx 
      host: localhost
    user_table: users 
    username_column: userlogin 
    password_column: userpass

# By default, we use the 'simple' theme which you can find in themes/simple.
theme: simple

# The name of your company/organization. This will show up on the login page.
organization: xxxx 

login_redirect: true 
#login_redirect: false
login_redirect_url: http://xxx.xxx.com 

log:
  file: log/casserver.log
  level: DEBUG

db_log:
  file: log/casserver_db.log
  level: DEBUG

downcase_username: true

enable_single_sign_out: true
____________

Matt Zukowski

unread,
May 4, 2014, 4:38:50 PM5/4/14
to RubyCAS
The config file looks right, so it's got to be something else going on. I should've asked for it earlier, but can you post part of your log/casserver.log and log/casserver_db.log, showing what happens when a user logs in? In the _db.log it should show which field in your users table it's actually quering.


--
You received this message because you are subscribed to the Google Groups "RubyCAS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubycas-serve...@googlegroups.com.
To post to this group, send email to rubycas...@googlegroups.com.
Visit this group at http://groups.google.com/group/rubycas-server.
For more options, visit https://groups.google.com/d/optout.

Noora

unread,
May 5, 2014, 3:11:50 AM5/5/14
to rubycas...@googlegroups.com, ma...@roughest.net
Yep, sure. Here are both of the log files. 

______

# tail -10 casserver.log 

CREATING USER MODEL CASUser_0

Done setting up CASServer::Authenticators::SQL.

Redirecting ActiveRecord log to log/casserver.log

About to setup CASServer::Authenticators::SQL with {"class"=>"CASServer::Authenticators::SQL", "database"=>{"adapter"=>"mysql2", "database"=>"XXXX", "username"=>"XXX", "password"=>"XXXXXXX", "host"=>"localhost"}, "user_table"=>"users", "username_column"=>"userlogin", "password_column"=>"userpass"}...

CREATING USER MODEL CASUser_0

Done setting up CASServer::Authenticators::SQL.

Redirecting ActiveRecord log to log/casserver.log

About to setup CASServer::Authenticators::SQL with {"class"=>"CASServer::Authenticators::SQL", "database"=>{"adapter"=>"mysql2", "database"=>"XXXX", "username"=>"XXX", "password"=>"XXXXXXX", "host"=>"localhost"}, "user_table"=>"users", "username_column"=>"userlogin", "password_column"=>"userpass"}...

CREATING USER MODEL CASUser_0

Done setting up CASServer::Authenticators::SQL.

______

# tail -10 casserver_db.log 

  CASServer::Model::TicketGrantingTicket Load (0.6ms)  SELECT `casserver_tgt`.* FROM `casserver_tgt` WHERE `casserver_tgt`.`ticket` = 'TGC-1398770282rAGM-2V2MIGDKwiiCHe' LIMIT 1

   (0.1ms)  BEGIN

  SQL (0.4ms)  INSERT INTO `casserver_lt` (`client_hostname`, `consumed`, `created_on`, `ticket`) VALUES ('206.196.26.68', NULL, '2014-04-29 13:13:38', 'LT-1398773618rpdJbE1yiqlzR3LuzRL')

   (9.3ms)  COMMIT

  CASServer::Authenticators::SQL::CASUser_0 Load (0.3ms)  SELECT `users`.* FROM `users` WHERE (userlogin = 'X...@gmail.com' AND userpass = '$P$BZ64Na9ppYcIXr6pBbrglGXMUnzkE1/')

  CASServer::Authenticators::SQL::CASUser_0 Load (0.5ms)  SELECT `users`.* FROM `users` WHERE (userlogin = 'x...@yahoo.com' AND userpass = '$P$BOAVGJmtkYXq2yGUcUn6lAyO5bnPCV.')

  CASServer::Authenticators::SQL::CASUser_0 Load (0.6ms)  SELECT `users`.* FROM `users` WHERE (userlogin = 'tes...@grr.la' AND userpass = '$P$BOQH1IBfZGh4BGmk6p1z3NL3Ug6Kxy0')

   (0.1ms)  BEGIN

  SQL (0.5ms)  INSERT INTO `casserver_lt` (`client_hostname`, `consumed`, `created_on`, `ticket`) VALUES ('117.77.16.189', NULL, '2014-05-05 07:58:57', 'LT-1399273137rQpmJURWg0OfoQsisRO')

   (25.3ms)  COMMIT

______

This is how I figured that rubycas was still pulling from the email column, because the log is still listing the email addresses, even though that userlogin column has no emails in it. I guess this means there's no cache I can clear?

Robert Mitwicki

unread,
May 5, 2014, 5:25:28 AM5/5/14
to rubycas...@googlegroups.com
Hi ,

> However, rubycas is still pointing to the email column, according to our log file.

Where do you see that in log. As I can see everything in log is correct.
In config file you setup `userlogin`:

> user_table: users
> username_column: userlogin

and in log file:

> CASServer::Authenticators::SQL::CASUser_0 Load (0.3ms) SELECT `users`.* FROM `users` > WHERE (userlogin = 'X...@gmail.com' AND userpass ='...')

So rubycas is using correct field.

Few questions to make it easier to understand:
1) Users are using emails as their login or they have separate login
field for that purpose?
2) Are you storing email addresses in your database in userlogin or just logins?


Best regards

Matt Zukowski

unread,
May 5, 2014, 10:52:22 AM5/5/14
to RubyCAS
Like Robert said, in your config you have  username_column: userlogin . What this means is that when a user fills out the CAS login form (Username and Password), the server will take what they entered for the Username part and check it against what you have in "username_column" — in your case, "userlogin". That's exactly what it's doing. However it looks like users are entering their email address rather than username. Maybe you want to change "username_column" to "email" (or whatever the column that has their email address is called in your database).

Alternatively, I wonder if the problem is that the label on the login form is wrong. Maybe it says "Email", but you want it to say "Username"? The config.yml file you posted seems to be using the default template, but I wonder if the wording was changed there manually? Try to find the file "lib/casserver/views/_login_form.erb" somewhere in your RubyCAS-Server installation. I wonder if this line has been changed: https://github.com/rubycas/rubycas-server/blob/master/lib/casserver/views/_login_form.erb#L8

Another possibility is that the username label was changed somewhere in the language translations. In that case it would be under in one of the files under the "locales" directory (i.e. something like this: https://github.com/rubycas/rubycas-server/tree/master/locales)


Noora

unread,
May 6, 2014, 2:54:39 AM5/6/14
to rubycas...@googlegroups.com
Hi -

Well, in the log it's showing the correct column (userlogin), but it's grabbing their emails instead of their usernames. 

To answer your questions:

Basically, our users sign up for an account on our website using a custom login form. If they try to put in their email address as their login, it'll just drop the @email.com part and insert just the first part. So joh...@gmail.com will just become 'johndoe'. It'll then insert that into the userlogin column. 

They do have to register with both a login and an email address, but the email goes into a separate database column called 'emails'. In the end, the database is like this:

First name
Last name
Userlogin (absolutely no emails allowed here, as the system will drop the @email.com part)
Emails

So the log file is showing that rubycas is using the correct column (userlogin), but I don't understand why their emails addresses from the 'emails' column is showing up in the log file. I've double and triple checked our database and there are absolutely no emails listed in that userlogin column. 

I appreciate all the help, though.

Noora

unread,
May 6, 2014, 3:10:13 AM5/6/14
to rubycas...@googlegroups.com, ma...@roughest.net

I've checked the database and login form again and everything looks normal, like it should. Our users actually fill out our own customized login form from our external website, which inserts their details into the database. Then rubycas just reads their usernames and passwords from the database so they can login to our internal website. But I did check out _login_form.erb and it looks standard, even though we don't make use of that form.

Our external website that doesn't use rubycas is getting the correct logins. I just don't get it; there must be something going wrong here, maybe it's something in the code the developer modified and forgot about. I can't think of anything else! What I'm going to do is just re-install rubycas from scratch myself and see how it goes. It'll probably be easier than trying to track down this issue.

Matt, Robert, I appreciate all your time in helping me out here. wish me luck!

Matt Zukowski

unread,
May 6, 2014, 11:01:00 AM5/6/14
to RubyCAS
Noora, I'm pretty sure whatever is going on here is not a problem on the RubyCAS side. From the logs it looks like everything is working fine — the problem is that the information being sent to the RubyCAS server for the 'username' column is an email address. This has to be happening somewhere further up, probably in how your custom login form sends its data to the server.
Reply all
Reply to author
Forward
0 new messages