Я столкнулся с этой же проблемой. К сожалению, похоже, что это конструктивный недостаток CarrierWave ... он не позволяет правильно проверить удаленный URL.
CarrierWave попытается загрузить ресурс сразу же, когда атрибут будет установлен, и выдаст исключение, если URL недействителен, недоступен или если ресурс не имеет ожидаемого типа.
DownloadError или IntegrityErrors всегда генерируются перед проверкой.
Поэтому я не смог найти хороший обходной путь, который бы использовал другие валидаторы. Мое решение в итоге выглядело так:
valid = false
begin
par = params[:image].except(:remote_upload_url)
@image = Image.new(par)
# this may fail:
@image.remote_upload_url = params[:image][:remote_upload_url]
valid = true
rescue CarrierWave::DownloadError
@image.errors.add(:remote_upload_url, "This url doesn't appear to be valid")
rescue CarrierWave::IntegrityError
@image.errors.add(:remote_upload_url, "This url does not appear to point to a valid image")
end
# validate and save if no exceptions were thrown above
if valid && @image.save
redirect_to(images_configure_path)
else
render :action => 'new'
end
По сути, я обертываю конструктор в блоке восстановления и первоначально устанавливаю все параметры, кроме удаленного URL. Когда я устанавливаю это, может возникнуть исключение, которое я обрабатываю, вручную устанавливая ошибку в модели. Обратите внимание, что в этом сценарии другие проверки не выполняются. Это взлом, но работал для меня.
Я надеюсь, что это можно будет решить в следующем выпуске, отложив загрузку ресурса до этапа проверки модели или после него.