Bug #10167

[SSO] sso server adds multiple records without checking

Added by Nico César almost 3 years ago. Updated almost 3 years ago.

Status:
New
Priority:
Normal
Assigned To:
-
Category:
SSO
Target version:
Start date:
09/29/2016
Due date:
% Done:

0%

Estimated time:
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.

History

#1 Updated by Nico César almost 3 years ago

  • Description updated (diff)

#2 Updated by Javier Bértoli almost 3 years ago

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

Also available in: Atom PDF