required_params will be matched with actual params to check if the token
may be used for authorization. For example if { job_id: 44 } is passed
as a required param, the token will be rejected for GET /jobs/33
This commit changes travis-api to always return 404 response if resource
is not available. Previously we were returning image/png with "unknown"
status instead if user used "*/*" Accept header, which was confusing.
This hack is temporary and should be removed when we find better
solution.
TL;DR: we can't handle redirects to S3 using CORS, so in case we want to
get logs from S3 without additional requests to API, we need to return
status that will not be automatically redirected (in this case 204 seems
like the best answer).
Longer rationale:
Old logs are hosted on S3 now and in case log is not available in the
database, we would like to redirect to the archived log. Although S3
support CORS, our use case breaks on some browsers:
* when request is triggered to /jobs/:id/log and log is archived, api
returns 302 redirect, Location header points to the log on S3
* browser transparently redirects to given url, but it sets Origin to
null, for security reasons
* "Origin: null" is ok, because we allow every origin by setting
AllowedOrigin to "*"
* S3 returns "Access-Control-Allow-Origin: null" header, which breaks
some browsers (I confirmed it for webkit based browsers)
In order to fix this, S3 would need to return * in
Access-Control-Allow-Origin header or we would need to tell the browser
to not follow redirect. Both solutions are not achiveable.
Another option would be to return log information in job payload - we
could send log_url field which should be either log url on amazon or
null, but in such case we would need to query artifacts table in each
job request. This is something that should be avoided as archived logs
are not frequently requested - slowing down every request to get info
for it would be a waste.
We can do it, because we use :transaction strategy with DatabaseCleaner,
which starts transaction before each test and rollbacks after it. That
way data before each test is consistent.
The big advantage of such approach is that tests are fast now - we need
to only load Scenario data once.
One of the drawbacks, on the other hand, is that we need to always load
this data, even if no integration tests need running.
We can try to be smart about it and check if any integration tests are
loaded.
