Issue 13517

Website link is trying to open http://uat.gbif....

13517
Reporter: trobertson
Assignee: kbraak
Type: Bug
Summary: Website link is trying to open    http://uat.gbif....
Priority: Blocker
Resolution: Fixed
Status: Closed
Created: 2013-07-17 11:34:10.082
Updated: 2013-08-22 10:59:45.576
Resolved: 2013-08-22 10:59:45.54
        
        
Description: Website link is trying to open
  http://uat.gbif.org/publisher/www.wii.gov.in

Where it should open
  http://www.wii.gov.in]]>
    


Author: kbraak@gbif.org
Comment: Fix committed in https://code.google.com/p/gbif-portal/source/detail?r=1807
Created: 2013-08-20 12:21:03.616
Updated: 2013-08-20 12:21:03.616


Author: mdoering@gbif.org
Comment: I would much more prefer if we solve the issue in the underlying data instead. How can we best enforce that all URLs (homepage & logo) are absolute URIs?
Created: 2013-08-20 12:37:16.268
Updated: 2013-08-20 12:37:16.268


Author: mdoering@gbif.org
Created: 2013-08-20 12:43:57.26
Updated: 2013-08-20 12:44:44.691
        
maybe just use a regex validation pattern?
@Pattern(regexp = "^http", message = "Absolute http or https url required")

Plus making sure our db is fine after migration?
Eh, thats for strings, but we have a URI instance already
    


Author: kbraak@gbif.org
Created: 2013-08-20 13:59:44.087
Updated: 2013-08-20 13:59:44.087
        
I can confirm, that @Pattern is only for Strings. http://docs.oracle.com/javaee/6/api/javax/validation/constraints/Pattern.html

Indeed, Organization.homepage is of type URI already for example. After migration, there are 21 organization homepage URI that don't begin with http, i.e. www

Without the scheme (protocol) it is nevertheless still a valid URI. We could modify the URI scheme in the model object getter though:

  @Nullable
  public URI getHomepage() {
    return homepage;
  }

Whatever we decide, the change could apply to various other places in our API also, such as DataDescription.url


    


Author: mdoering@gbif.org
Created: 2013-08-20 15:10:08.455
Updated: 2013-08-20 15:10:08.455
        
I think we should try to not have such data in our registry at all. We should be able to do so by:
 * Fixing migration scripts, adding the missing http:// if necessary
 * adding validation or setting a protocol scheme in the setter/persistence layer
    


Author: kbraak@gbif.org
Created: 2013-08-20 17:18:17.774
Updated: 2013-08-20 17:18:17.774
        
I have gone with changing the migration script. Work committed in https://code.google.com/p/gbif-labs/source/detail?r=501

Following successful review, I can modify the script in similar places if need be. What do you think? 
    


Author: mdoering@gbif.org
Comment: Sounds good, just a minor comment in the diff. Even with the migration script in place we then need a validation of absolute URIs somehow, could simply be a new issue for now
Created: 2013-08-20 18:31:45.947
Updated: 2013-08-20 18:31:45.947


Author: kbraak@gbif.org
Comment: Review for proposed constrain validation annotation created: http://dev.gbif.org/code/cru/CR-GBIFCOM-50
Created: 2013-08-21 18:37:02.103
Updated: 2013-08-21 18:37:02.103


Author: kbraak@gbif.org
Created: 2013-08-22 10:59:45.573
Updated: 2013-08-22 10:59:45.573
        
With the constraint validation annotation applied to the API for all Registry's homepage and logo_urls, this issue can now be considered closed.

Change to API was committed in https://code.google.com/p/gbif-common-resources/source/detail?r=1641 after being reviewed in http://dev.gbif.org/code/cru/CR-GBIFCOM-50