Actions
Bug #10167
closed[SSO] sso server adds multiple records without checking
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.
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?
Updated by Ward Vandewege over 3 years ago
- Target version deleted (
Arvados Future Sprints)
Actions