1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2024-11-24 15:52:41 +01:00
Commit graph

5 commits

Author SHA1 Message Date
epriestley
2a5c987c71 Lock policy queries to their applications
Summary:
While we mostly have reasonable effective object accessibility when you lock a user out of an application, it's primarily enforced at the controller level. Users can still, e.g., load the handles of objects they can't actually see. Instead, lock the queries to the applications so that you can, e.g., never load a revision if you don't have access to Differential.

This has several parts:

  - For PolicyAware queries, provide an application class name method.
  - If the query specifies a class name and the user doesn't have permission to use it, fail the entire query unconditionally.
  - For handles, simplify query construction and count all the PHIDs as "restricted" so we get a UI full of "restricted" instead of "unknown" handles.

Test Plan:
  - Added a unit test to verify I got all the class names right.
  - Browsed around, logged in/out as a normal user with public policies on and off.
  - Browsed around, logged in/out as a restricted user with public policies on and off. With restrictions, saw all traces of restricted apps removed or restricted.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Differential Revision: https://secure.phabricator.com/D7367
2013-10-21 17:20:27 -07:00
epriestley
a0f0ba6acd Stop using process/filesystem-based checks to determine if daemons are running
Summary:
We currently check if daemons are running using the filesystem and process list. These checks reach the wrong result for a lot of users because their webservers can't read the filesystem or process list. They also reach the wrong result for daemons running on other machines.

Instead, query the active daemon list to see if daemons are running. This should be significantly more reliable.

(We didn't do this before because the running daemon list mechanism didn't exist when the check was written, and at the time it was more complex than doing a simple filesystem/process list thing.)

Test Plan: Viewed `/repositories/` with and without daemons running, saw appropriate warning or lack of warning.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Differential Revision: https://secure.phabricator.com/D6722
2013-08-12 11:20:22 -07:00
epriestley
36c1359230 Allow long daemon log messages to be expanded
Summary:
Ref T3557. We summarize long messages, but don't let you see the entire message. This is occasionally inconvenient, and I'm planning to add more prefix junk to some messages for T2569.

Provide a link you can click to see the full message.

This isn't javascripted because a ton of these can make the page ridiculously enormous and it seems unlikely you'd care much about all of them.

Test Plan: {F51261} {F51262}

Reviewers: btrahan

Reviewed By: btrahan

CC: aran, chad

Maniphest Tasks: T3557

Differential Revision: https://secure.phabricator.com/D6546
2013-07-23 16:58:02 -07:00
epriestley
e793a3657a Use a real Query class to load daemon information
Summary:
Ref T3557. This stuff does a bunch of nonsense in the View right now. Instead, do it in a real Query class.

Fixes a long-standing bug which prevented "all daemons" from showing more than 3 days' worth of data.

Test Plan: Viewed `/daemon/`, viewed "All Daemons".

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T3557

Differential Revision: https://secure.phabricator.com/D6544
2013-07-23 12:11:34 -07:00
epriestley
40226bbfd0 Mostly modernize daemon detail views
Summary:
Ref T3557. The major goals here are:

  - Modernize use of UI elements.
  - Present daemon status with more clarity. Particularly, the "Waiting" status is called out and explained in detail.

Test Plan:
{F51247}

{F51248}

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T3557

Differential Revision: https://secure.phabricator.com/D6541
2013-07-23 12:10:41 -07:00