This sets up all the basics for importing Phabricator tasks into
GitLab issues.
To import all tasks from a Phabricator instance into GitLab, we'll
import all of them into a new project that will have its repository
disabled.
The import is hooked into a regular ProjectImport setup, but similar
to the GitHub parallel importer takes care of all the imports itself.
In this iteration, we're importing each page of tasks in a separate
sidekiq job.
The first thing we do when requesting a new page of tasks is schedule
the next page to be imported. But to avoid deadlocks, we only allow a
single job per worker type to run at the same time.
For now we're only importing basic Issue information, this should be
extended to richer information.
This change is a fairly straightforward refactor to extract the tracing
and correlation-id code from the gitlab rails codebase into the new
LabKit-Ruby project.
The corresponding import into LabKit-Ruby was in
https://gitlab.com/gitlab-org/labkit-ruby/merge_requests/1
The code itself remains very similar for now.
Extracting it allows us to reuse it in other projects, such as
Gitaly-Ruby. This will give us the advantages of correlation-ids and
distributed tracing in that project too.
`queue_duration` is a useful metric that is currently in api_json.log
but not in production_json.log. We should add it because it tells us how
long the request sat in Workhorse before Unicorn processed it. Having
this field enables the support team to better troubleshoot when delays
began to happen.
The Correlation ID is taken or generated from received X-Request-ID.
Then it is being passed to all executed services (sidekiq workers
or gitaly calls).
The Correlation ID is logged in all structured logs as `correlation_id`.
Adds gitlab.impersonation_enabled config option defaulting to true to
keep the current default behaviour.
Only the act of impersonation is modified, impersonation token
management is not affected.
[master] Resolve "Personal access token with only `read_user` scope can be used to authenticate any web request"
See merge request gitlab/gitlabhq!2583
In Rails 5 catches invalid UTF8 characters in querystring in a
params middleware, errors are handled by a params middleware and
raises a BadRequest exception. This means that these UTF8 errors
are not raised deeper in application stack and these can't also
be handled on application level.
If we would want to have custom handler for these errors, we would
have to create a new middleware and insert it before actionpack's
params middleware and rescue BadRequest exceptions there. But there
is no need to do this currently (see discussion on
https://gitlab.com/gitlab-org/gitlab-ce/issues/51908)
Was introduced in the time that GitLab still used NFS, which is not
required anymore in most cases. By removing this, the API it calls will
return empty responses. This interface has to be removed in the next
major release, expected to be 12.0.
By default, all sessions are given the same expiration time configured in the
session store (e.g. 1 week). However, unauthenticated users can generate a lot
of sessions, primarily for CSRF verification. It makes sense to reduce the TTL
for unauthenticated to something much lower than the default (e.g. 1 hour) to
limit Redis memory. In addition, Rails creates a new session after login,
so the short TTL doesn't even need to be extended.
Closes#48101
Since Rails 5.0 the `protect_from_forgery` callback doesn't run first by
default anymore. [1]
Instead it gets inserted into callbacks chain where callbacks get
called in order.
This commit forces the callback to run first.
[1]: 3979403781
The `errors/access_denied` page should not fail to render when no
message is provided.
When accessing something as a sessionless user, we should also display
the terms message if possible.
We have a number of import errors occurring with 422 errors, and
it's hard to determine why they are happening. This change will
surface the errors in the log lines.
Relates to #47365
When we want to show an access denied message to a user, we don't have
to hide the resource's existence.
So in that case we render a 403, this 403 is not handled by nginx on
omnibus installs, making sure the message is visible to the user.