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 #1

Updated by Nico César over 7 years ago

  • Description updated (diff)
Actions #2

Updated by Javier Bértoli over 7 years ago

Maybe, in both cases, (clients table and users table) a constraint for UNIQUE in the relevant fields will do the trick?

Actions #3

Updated by Peter Amstutz over 3 years ago

  • Status changed from New to Closed
Actions #4

Updated by Ward Vandewege over 3 years ago

  • Target version deleted (Arvados Future Sprints)
Actions

Also available in: Atom PDF