Project

General

Profile

Actions

Bug #10167

closed

[SSO] sso server adds multiple records without checking

Added by Nico César over 7 years ago. Updated over 3 years ago.

Status:
Closed
Priority:
Normal
Assigned To:
-
Category:
SSO
Target version:
-
Story points:
-

Description

version arvados-sso-server-0.1.20160603200933.4ed9c48-6.x86_64

[root@sso current]# cd /var/www/arvados-sso/current; export RAILS_ENV=production; `which rvm-exec` default bundle exec rails console 
Loading production environment (Rails 3.2.8)
2.1.10 :001 > c = Client.new
 => #<Client id: nil, name: nil, app_id: nil, app_secret: nil, created_at: nil, updated_at: nil> 
2.1.10 :002 > c.name = "test" 
 => "test" 
2.1.10 :003 > c.app_id = "arvados-server" 
 => "arvados-server" 
2.1.10 :004 > c.app_secret = "secret" 
 => "secret" 
2.1.10 :005 > c.save!
   (0.1ms)  BEGIN
  SQL (3.2ms)  INSERT INTO "clients" ("app_id", "app_secret", "created_at", "name", "updated_at") VALUES ($1, $2, $3, $4, $5) RETURNING "id"  [["app_id", "arvados-server"], ["app_secret", "secret"], ["created_at", Thu, 29 Sep 2016 19:16:14 UTC +00:00], ["name", "test"], ["updated_at", Thu, 29 Sep 2016 19:16:14 UTC +00:00]]
   (0.8ms)  COMMIT
 => true 
2.1.10 :006 > quit

If I do it again, it creates a second row-

Loading production environment (Rails 3.2.8)
2.1.10 :001 > c = Client.new
 => #<Client id: nil, name: nil, app_id: nil, app_secret: nil, created_at: nil, updated_at: nil> 
2.1.10 :002 > c.name = "test" 
 => "test" 
2.1.10 :003 > c.app_id = "arvados-server" 
 => "arvados-server" 
2.1.10 :004 > c.app_secret = "secret" 
 => "secret" 
2.1.10 :005 > c.save!
   (0.1ms)  BEGIN
  SQL (3.2ms)  INSERT INTO "clients" ("app_id", "app_secret", "created_at", "name", "updated_at") VALUES ($1, $2, $3, $4, $5) RETURNING "id"  [["app_id", "arvados-server"], ["app_secret", "secret"], ["created_at", Thu, 29 Sep 2016 19:17:30 UTC +00:00], ["name", "test"], ["updated_at", Thu, 29 Sep 2016 19:17:30 UTC +00:00]]
   (1.1ms)  COMMIT
 => true 
2.1.10 :006 > 

the desired behavior is to have a check and complain if it already exists.

The same happens with users table, but is likely that workbench is doing that check so our production services don't have multiple copies of users.

Actions

Also available in: Atom PDF