1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2024-12-11 08:06:13 +01:00
phorge-phorge/src/applications/phame/storage/PhameBlog.php

395 lines
10 KiB
PHP
Raw Normal View History

<?php
final class PhameBlog extends PhameDAO
implements
PhabricatorPolicyInterface,
PhabricatorMarkupInterface,
PhabricatorSubscribableInterface,
PhabricatorFlaggableInterface,
PhabricatorProjectInterface,
PhabricatorDestructibleInterface,
PhabricatorApplicationTransactionInterface,
PhabricatorConduitResultInterface,
PhabricatorFulltextInterface,
PhabricatorFerretInterface {
const MARKUP_FIELD_DESCRIPTION = 'markup:description';
protected $name;
protected $subtitle;
protected $description;
protected $domain;
protected $domainFullURI;
protected $parentSite;
protected $parentDomain;
protected $configData;
protected $creatorPHID;
protected $viewPolicy;
protected $editPolicy;
protected $status;
protected $mailKey;
protected $profileImagePHID;
protected $headerImagePHID;
private $profileImageFile = self::ATTACHABLE;
private $headerImageFile = self::ATTACHABLE;
const STATUS_ACTIVE = 'active';
const STATUS_ARCHIVED = 'archived';
protected function getConfiguration() {
return array(
self::CONFIG_AUX_PHID => true,
self::CONFIG_SERIALIZATION => array(
'configData' => self::SERIALIZATION_JSON,
),
self::CONFIG_COLUMN_SCHEMA => array(
'name' => 'text64',
'subtitle' => 'text64',
'description' => 'text',
'domain' => 'text128?',
'domainFullURI' => 'text128?',
'parentSite' => 'text128?',
'parentDomain' => 'text128?',
'status' => 'text32',
'mailKey' => 'bytes20',
'profileImagePHID' => 'phid?',
'headerImagePHID' => 'phid?',
// T6203/NULLABILITY
// These policies should always be non-null.
'editPolicy' => 'policy?',
'viewPolicy' => 'policy?',
),
self::CONFIG_KEY_SCHEMA => array(
'key_phid' => null,
'phid' => array(
'columns' => array('phid'),
'unique' => true,
),
'domain' => array(
'columns' => array('domain'),
'unique' => true,
),
),
) + parent::getConfiguration();
}
public function save() {
if (!$this->getMailKey()) {
$this->setMailKey(Filesystem::readRandomCharacters(20));
}
return parent::save();
}
public function generatePHID() {
return PhabricatorPHID::generateNewPHID(
PhabricatorPhameBlogPHIDType::TYPECONST);
}
public static function initializeNewBlog(PhabricatorUser $actor) {
$blog = id(new PhameBlog())
->setCreatorPHID($actor->getPHID())
->setStatus(self::STATUS_ACTIVE)
->setViewPolicy(PhabricatorPolicies::getMostOpenPolicy())
->setEditPolicy(PhabricatorPolicies::POLICY_USER);
return $blog;
}
public function isArchived() {
return ($this->getStatus() == self::STATUS_ARCHIVED);
}
public static function getStatusNameMap() {
return array(
self::STATUS_ACTIVE => pht('Active'),
self::STATUS_ARCHIVED => pht('Archived'),
);
}
/**
* Makes sure a given custom blog uri is properly configured in DNS
* to point at this Phabricator instance. If there is an error in
* the configuration, return a string describing the error and how
* to fix it. If there is no error, return an empty string.
*
* @return string
*/
public function validateCustomDomain($domain_full_uri) {
$example_domain = 'http://blog.example.com/';
$label = pht('Invalid');
// note this "uri" should be pretty busted given the desired input
// so just use it to test if there's a protocol specified
$uri = new PhutilURI($domain_full_uri);
$domain = $uri->getDomain();
$protocol = $uri->getProtocol();
$path = $uri->getPath();
$supported_protocols = array('http', 'https');
if (!in_array($protocol, $supported_protocols)) {
return pht(
'The custom domain should include a valid protocol in the URI '.
'(for example, "%s"). Valid protocols are "http" or "https".',
$example_domain);
}
if (strlen($path) && $path != '/') {
return pht(
'The custom domain should not specify a path (hosting a Phame '.
'blog at a path is currently not supported). Instead, just provide '.
'the bare domain name (for example, "%s").',
$example_domain);
}
if (strpos($domain, '.') === false) {
return pht(
'The custom domain should contain at least one dot (.) because '.
'some browsers fail to set cookies on domains without a dot. '.
'Instead, use a normal looking domain name like "%s".',
$example_domain);
}
if (!PhabricatorEnv::getEnvConfig('policy.allow-public')) {
$href = PhabricatorEnv::getProductionURI(
'/config/edit/policy.allow-public/');
return pht(
'For custom domains to work, this Phabricator instance must be '.
'configured to allow the public access policy. Configure this '.
'setting %s, or ask an administrator to configure this setting. '.
'The domain can be specified later once this setting has been '.
'changed.',
phutil_tag(
'a',
array('href' => $href),
pht('here')));
}
return null;
}
Remove skins from Phame Summary: Ref T9897. Purge a bunch of stuff: - Remove skins. - Remove all custom sites for skin resources. - Remove "framed", "notlive", "preview", separate "live" controllers (see below). - Merge "publish" and "unpublish" controllers into one. New behavior: - Blogs and posts have three views: - "View": Internal view URI, which is a normal detail page. - "Internal Live": Internal view URI which is a little prettier. - "External Live": External view URI for an external domain. Right now, the differences are pretty minor (basically, different crumbs/chrome). This mostly gives us room to put some milder flavor of skins back later (photography or more "presentation" elements, for example). This removes 9 million lines of code so I probably missed a couple of things, but I think it's like 95% of the way there. Test Plan: Here are some examples of what the "view", "internal" and "external" views look like for blogs (posts are similar): "View": Unchanged {F1021634} "Internal": No chrome or footer. Still write actions (edit, post commments). Has crumbs to get back into Phame. {F1021635} "External": No chrome or footer. No write actions. No Phabricator crumbs. No policy/status information. {F1021638} I figure we'll probably tweak these a bit to figure out what makes sense (like: maybe no actions on "internal, live"? and "external, live" probably needs a way to set a root "Company >" crumb?) but that they're reasonable-ish as a first cut? Reviewers: chad Reviewed By: chad Maniphest Tasks: T9897 Differential Revision: https://secure.phabricator.com/D14740
2015-12-11 16:07:45 +01:00
public function getLiveURI() {
if (strlen($this->getDomain())) {
return $this->getExternalLiveURI();
Don't 302 to an external URI, even after CSRF POST Summary: Via HackerOne. This defuses an attack which allows users to steal OAuth tokens through a clever sequence of steps: - The attacker begins the OAuth workflow and copies the Facebook URL. - The attacker mutates the URL to use the JS/anchor workflow, and to redirect to `/phame/live/X/` instead of `/login/facebook:facebook.com/`, where `X` is the ID of some blog they control. Facebook isn't strict about paths, so this is allowed. - The blog has an external domain set (`blog.evil.com`), and the attacker controls that domain. - The user gets stopped on the "live" controller with credentials in the page anchor (`#access_token=...`) and a message ("This blog has moved...") in a dialog. They click "Continue", which POSTs a CSRF token. - When a user POSTs a `<form />` with no `action` attribute, the browser retains the page anchor. So visiting `/phame/live/8/#anchor` and clicking the "Continue" button POSTs you to a page with `#anchor` intact. - Some browsers (including Firefox and Chrome) retain the anchor after a 302 redirect. - The OAuth credentials are thus preserved when the user reaches `blog.evil.com`, and the attacker's site can read them. This 302'ing after CSRF post is unusual in Phabricator and unique to Phame. It's not necessary -- instead, just use normal links, which drop anchors. I'm going to pursue further steps to mitigate this class of attack more thoroughly: - Ideally, we should render forms with an explicit `action` attribute, but this might be a lot of work. I might render them with `#` if no action is provided. We never expect anchors to survive POST, and it's surprising to me that they do. - I'm going to blacklist OAuth parameters (like `access_token`) from appearing in GET on all pages except whitelisted pages (login pages). Although it's not important here, I think these could be captured from referrers in some cases. See also T4342. Test Plan: Browsed all the affected Phame interfaces. Reviewers: btrahan Reviewed By: btrahan CC: aran, arice Differential Revision: https://secure.phabricator.com/D8481
2014-03-11 00:21:07 +01:00
} else {
Remove skins from Phame Summary: Ref T9897. Purge a bunch of stuff: - Remove skins. - Remove all custom sites for skin resources. - Remove "framed", "notlive", "preview", separate "live" controllers (see below). - Merge "publish" and "unpublish" controllers into one. New behavior: - Blogs and posts have three views: - "View": Internal view URI, which is a normal detail page. - "Internal Live": Internal view URI which is a little prettier. - "External Live": External view URI for an external domain. Right now, the differences are pretty minor (basically, different crumbs/chrome). This mostly gives us room to put some milder flavor of skins back later (photography or more "presentation" elements, for example). This removes 9 million lines of code so I probably missed a couple of things, but I think it's like 95% of the way there. Test Plan: Here are some examples of what the "view", "internal" and "external" views look like for blogs (posts are similar): "View": Unchanged {F1021634} "Internal": No chrome or footer. Still write actions (edit, post commments). Has crumbs to get back into Phame. {F1021635} "External": No chrome or footer. No write actions. No Phabricator crumbs. No policy/status information. {F1021638} I figure we'll probably tweak these a bit to figure out what makes sense (like: maybe no actions on "internal, live"? and "external, live" probably needs a way to set a root "Company >" crumb?) but that they're reasonable-ish as a first cut? Reviewers: chad Reviewed By: chad Maniphest Tasks: T9897 Differential Revision: https://secure.phabricator.com/D14740
2015-12-11 16:07:45 +01:00
return $this->getInternalLiveURI();
Don't 302 to an external URI, even after CSRF POST Summary: Via HackerOne. This defuses an attack which allows users to steal OAuth tokens through a clever sequence of steps: - The attacker begins the OAuth workflow and copies the Facebook URL. - The attacker mutates the URL to use the JS/anchor workflow, and to redirect to `/phame/live/X/` instead of `/login/facebook:facebook.com/`, where `X` is the ID of some blog they control. Facebook isn't strict about paths, so this is allowed. - The blog has an external domain set (`blog.evil.com`), and the attacker controls that domain. - The user gets stopped on the "live" controller with credentials in the page anchor (`#access_token=...`) and a message ("This blog has moved...") in a dialog. They click "Continue", which POSTs a CSRF token. - When a user POSTs a `<form />` with no `action` attribute, the browser retains the page anchor. So visiting `/phame/live/8/#anchor` and clicking the "Continue" button POSTs you to a page with `#anchor` intact. - Some browsers (including Firefox and Chrome) retain the anchor after a 302 redirect. - The OAuth credentials are thus preserved when the user reaches `blog.evil.com`, and the attacker's site can read them. This 302'ing after CSRF post is unusual in Phabricator and unique to Phame. It's not necessary -- instead, just use normal links, which drop anchors. I'm going to pursue further steps to mitigate this class of attack more thoroughly: - Ideally, we should render forms with an explicit `action` attribute, but this might be a lot of work. I might render them with `#` if no action is provided. We never expect anchors to survive POST, and it's surprising to me that they do. - I'm going to blacklist OAuth parameters (like `access_token`) from appearing in GET on all pages except whitelisted pages (login pages). Although it's not important here, I think these could be captured from referrers in some cases. See also T4342. Test Plan: Browsed all the affected Phame interfaces. Reviewers: btrahan Reviewed By: btrahan CC: aran, arice Differential Revision: https://secure.phabricator.com/D8481
2014-03-11 00:21:07 +01:00
}
Remove skins from Phame Summary: Ref T9897. Purge a bunch of stuff: - Remove skins. - Remove all custom sites for skin resources. - Remove "framed", "notlive", "preview", separate "live" controllers (see below). - Merge "publish" and "unpublish" controllers into one. New behavior: - Blogs and posts have three views: - "View": Internal view URI, which is a normal detail page. - "Internal Live": Internal view URI which is a little prettier. - "External Live": External view URI for an external domain. Right now, the differences are pretty minor (basically, different crumbs/chrome). This mostly gives us room to put some milder flavor of skins back later (photography or more "presentation" elements, for example). This removes 9 million lines of code so I probably missed a couple of things, but I think it's like 95% of the way there. Test Plan: Here are some examples of what the "view", "internal" and "external" views look like for blogs (posts are similar): "View": Unchanged {F1021634} "Internal": No chrome or footer. Still write actions (edit, post commments). Has crumbs to get back into Phame. {F1021635} "External": No chrome or footer. No write actions. No Phabricator crumbs. No policy/status information. {F1021638} I figure we'll probably tweak these a bit to figure out what makes sense (like: maybe no actions on "internal, live"? and "external, live" probably needs a way to set a root "Company >" crumb?) but that they're reasonable-ish as a first cut? Reviewers: chad Reviewed By: chad Maniphest Tasks: T9897 Differential Revision: https://secure.phabricator.com/D14740
2015-12-11 16:07:45 +01:00
}
Don't 302 to an external URI, even after CSRF POST Summary: Via HackerOne. This defuses an attack which allows users to steal OAuth tokens through a clever sequence of steps: - The attacker begins the OAuth workflow and copies the Facebook URL. - The attacker mutates the URL to use the JS/anchor workflow, and to redirect to `/phame/live/X/` instead of `/login/facebook:facebook.com/`, where `X` is the ID of some blog they control. Facebook isn't strict about paths, so this is allowed. - The blog has an external domain set (`blog.evil.com`), and the attacker controls that domain. - The user gets stopped on the "live" controller with credentials in the page anchor (`#access_token=...`) and a message ("This blog has moved...") in a dialog. They click "Continue", which POSTs a CSRF token. - When a user POSTs a `<form />` with no `action` attribute, the browser retains the page anchor. So visiting `/phame/live/8/#anchor` and clicking the "Continue" button POSTs you to a page with `#anchor` intact. - Some browsers (including Firefox and Chrome) retain the anchor after a 302 redirect. - The OAuth credentials are thus preserved when the user reaches `blog.evil.com`, and the attacker's site can read them. This 302'ing after CSRF post is unusual in Phabricator and unique to Phame. It's not necessary -- instead, just use normal links, which drop anchors. I'm going to pursue further steps to mitigate this class of attack more thoroughly: - Ideally, we should render forms with an explicit `action` attribute, but this might be a lot of work. I might render them with `#` if no action is provided. We never expect anchors to survive POST, and it's surprising to me that they do. - I'm going to blacklist OAuth parameters (like `access_token`) from appearing in GET on all pages except whitelisted pages (login pages). Although it's not important here, I think these could be captured from referrers in some cases. See also T4342. Test Plan: Browsed all the affected Phame interfaces. Reviewers: btrahan Reviewed By: btrahan CC: aran, arice Differential Revision: https://secure.phabricator.com/D8481
2014-03-11 00:21:07 +01:00
Remove skins from Phame Summary: Ref T9897. Purge a bunch of stuff: - Remove skins. - Remove all custom sites for skin resources. - Remove "framed", "notlive", "preview", separate "live" controllers (see below). - Merge "publish" and "unpublish" controllers into one. New behavior: - Blogs and posts have three views: - "View": Internal view URI, which is a normal detail page. - "Internal Live": Internal view URI which is a little prettier. - "External Live": External view URI for an external domain. Right now, the differences are pretty minor (basically, different crumbs/chrome). This mostly gives us room to put some milder flavor of skins back later (photography or more "presentation" elements, for example). This removes 9 million lines of code so I probably missed a couple of things, but I think it's like 95% of the way there. Test Plan: Here are some examples of what the "view", "internal" and "external" views look like for blogs (posts are similar): "View": Unchanged {F1021634} "Internal": No chrome or footer. Still write actions (edit, post commments). Has crumbs to get back into Phame. {F1021635} "External": No chrome or footer. No write actions. No Phabricator crumbs. No policy/status information. {F1021638} I figure we'll probably tweak these a bit to figure out what makes sense (like: maybe no actions on "internal, live"? and "external, live" probably needs a way to set a root "Company >" crumb?) but that they're reasonable-ish as a first cut? Reviewers: chad Reviewed By: chad Maniphest Tasks: T9897 Differential Revision: https://secure.phabricator.com/D14740
2015-12-11 16:07:45 +01:00
public function getExternalLiveURI() {
$uri = new PhutilURI($this->getDomainFullURI());
PhabricatorEnv::requireValidRemoteURIForLink($uri);
Remove skins from Phame Summary: Ref T9897. Purge a bunch of stuff: - Remove skins. - Remove all custom sites for skin resources. - Remove "framed", "notlive", "preview", separate "live" controllers (see below). - Merge "publish" and "unpublish" controllers into one. New behavior: - Blogs and posts have three views: - "View": Internal view URI, which is a normal detail page. - "Internal Live": Internal view URI which is a little prettier. - "External Live": External view URI for an external domain. Right now, the differences are pretty minor (basically, different crumbs/chrome). This mostly gives us room to put some milder flavor of skins back later (photography or more "presentation" elements, for example). This removes 9 million lines of code so I probably missed a couple of things, but I think it's like 95% of the way there. Test Plan: Here are some examples of what the "view", "internal" and "external" views look like for blogs (posts are similar): "View": Unchanged {F1021634} "Internal": No chrome or footer. Still write actions (edit, post commments). Has crumbs to get back into Phame. {F1021635} "External": No chrome or footer. No write actions. No Phabricator crumbs. No policy/status information. {F1021638} I figure we'll probably tweak these a bit to figure out what makes sense (like: maybe no actions on "internal, live"? and "external, live" probably needs a way to set a root "Company >" crumb?) but that they're reasonable-ish as a first cut? Reviewers: chad Reviewed By: chad Maniphest Tasks: T9897 Differential Revision: https://secure.phabricator.com/D14740
2015-12-11 16:07:45 +01:00
return (string)$uri;
}
Don't 302 to an external URI, even after CSRF POST Summary: Via HackerOne. This defuses an attack which allows users to steal OAuth tokens through a clever sequence of steps: - The attacker begins the OAuth workflow and copies the Facebook URL. - The attacker mutates the URL to use the JS/anchor workflow, and to redirect to `/phame/live/X/` instead of `/login/facebook:facebook.com/`, where `X` is the ID of some blog they control. Facebook isn't strict about paths, so this is allowed. - The blog has an external domain set (`blog.evil.com`), and the attacker controls that domain. - The user gets stopped on the "live" controller with credentials in the page anchor (`#access_token=...`) and a message ("This blog has moved...") in a dialog. They click "Continue", which POSTs a CSRF token. - When a user POSTs a `<form />` with no `action` attribute, the browser retains the page anchor. So visiting `/phame/live/8/#anchor` and clicking the "Continue" button POSTs you to a page with `#anchor` intact. - Some browsers (including Firefox and Chrome) retain the anchor after a 302 redirect. - The OAuth credentials are thus preserved when the user reaches `blog.evil.com`, and the attacker's site can read them. This 302'ing after CSRF post is unusual in Phabricator and unique to Phame. It's not necessary -- instead, just use normal links, which drop anchors. I'm going to pursue further steps to mitigate this class of attack more thoroughly: - Ideally, we should render forms with an explicit `action` attribute, but this might be a lot of work. I might render them with `#` if no action is provided. We never expect anchors to survive POST, and it's surprising to me that they do. - I'm going to blacklist OAuth parameters (like `access_token`) from appearing in GET on all pages except whitelisted pages (login pages). Although it's not important here, I think these could be captured from referrers in some cases. See also T4342. Test Plan: Browsed all the affected Phame interfaces. Reviewers: btrahan Reviewed By: btrahan CC: aran, arice Differential Revision: https://secure.phabricator.com/D8481
2014-03-11 00:21:07 +01:00
public function getExternalParentURI() {
$uri = $this->getParentDomain();
PhabricatorEnv::requireValidRemoteURIForLink($uri);
return (string)$uri;
}
Remove skins from Phame Summary: Ref T9897. Purge a bunch of stuff: - Remove skins. - Remove all custom sites for skin resources. - Remove "framed", "notlive", "preview", separate "live" controllers (see below). - Merge "publish" and "unpublish" controllers into one. New behavior: - Blogs and posts have three views: - "View": Internal view URI, which is a normal detail page. - "Internal Live": Internal view URI which is a little prettier. - "External Live": External view URI for an external domain. Right now, the differences are pretty minor (basically, different crumbs/chrome). This mostly gives us room to put some milder flavor of skins back later (photography or more "presentation" elements, for example). This removes 9 million lines of code so I probably missed a couple of things, but I think it's like 95% of the way there. Test Plan: Here are some examples of what the "view", "internal" and "external" views look like for blogs (posts are similar): "View": Unchanged {F1021634} "Internal": No chrome or footer. Still write actions (edit, post commments). Has crumbs to get back into Phame. {F1021635} "External": No chrome or footer. No write actions. No Phabricator crumbs. No policy/status information. {F1021638} I figure we'll probably tweak these a bit to figure out what makes sense (like: maybe no actions on "internal, live"? and "external, live" probably needs a way to set a root "Company >" crumb?) but that they're reasonable-ish as a first cut? Reviewers: chad Reviewed By: chad Maniphest Tasks: T9897 Differential Revision: https://secure.phabricator.com/D14740
2015-12-11 16:07:45 +01:00
public function getInternalLiveURI() {
return '/phame/live/'.$this->getID().'/';
Don't 302 to an external URI, even after CSRF POST Summary: Via HackerOne. This defuses an attack which allows users to steal OAuth tokens through a clever sequence of steps: - The attacker begins the OAuth workflow and copies the Facebook URL. - The attacker mutates the URL to use the JS/anchor workflow, and to redirect to `/phame/live/X/` instead of `/login/facebook:facebook.com/`, where `X` is the ID of some blog they control. Facebook isn't strict about paths, so this is allowed. - The blog has an external domain set (`blog.evil.com`), and the attacker controls that domain. - The user gets stopped on the "live" controller with credentials in the page anchor (`#access_token=...`) and a message ("This blog has moved...") in a dialog. They click "Continue", which POSTs a CSRF token. - When a user POSTs a `<form />` with no `action` attribute, the browser retains the page anchor. So visiting `/phame/live/8/#anchor` and clicking the "Continue" button POSTs you to a page with `#anchor` intact. - Some browsers (including Firefox and Chrome) retain the anchor after a 302 redirect. - The OAuth credentials are thus preserved when the user reaches `blog.evil.com`, and the attacker's site can read them. This 302'ing after CSRF post is unusual in Phabricator and unique to Phame. It's not necessary -- instead, just use normal links, which drop anchors. I'm going to pursue further steps to mitigate this class of attack more thoroughly: - Ideally, we should render forms with an explicit `action` attribute, but this might be a lot of work. I might render them with `#` if no action is provided. We never expect anchors to survive POST, and it's surprising to me that they do. - I'm going to blacklist OAuth parameters (like `access_token`) from appearing in GET on all pages except whitelisted pages (login pages). Although it's not important here, I think these could be captured from referrers in some cases. See also T4342. Test Plan: Browsed all the affected Phame interfaces. Reviewers: btrahan Reviewed By: btrahan CC: aran, arice Differential Revision: https://secure.phabricator.com/D8481
2014-03-11 00:21:07 +01:00
}
public function getViewURI() {
Remove skins from Phame Summary: Ref T9897. Purge a bunch of stuff: - Remove skins. - Remove all custom sites for skin resources. - Remove "framed", "notlive", "preview", separate "live" controllers (see below). - Merge "publish" and "unpublish" controllers into one. New behavior: - Blogs and posts have three views: - "View": Internal view URI, which is a normal detail page. - "Internal Live": Internal view URI which is a little prettier. - "External Live": External view URI for an external domain. Right now, the differences are pretty minor (basically, different crumbs/chrome). This mostly gives us room to put some milder flavor of skins back later (photography or more "presentation" elements, for example). This removes 9 million lines of code so I probably missed a couple of things, but I think it's like 95% of the way there. Test Plan: Here are some examples of what the "view", "internal" and "external" views look like for blogs (posts are similar): "View": Unchanged {F1021634} "Internal": No chrome or footer. Still write actions (edit, post commments). Has crumbs to get back into Phame. {F1021635} "External": No chrome or footer. No write actions. No Phabricator crumbs. No policy/status information. {F1021638} I figure we'll probably tweak these a bit to figure out what makes sense (like: maybe no actions on "internal, live"? and "external, live" probably needs a way to set a root "Company >" crumb?) but that they're reasonable-ish as a first cut? Reviewers: chad Reviewed By: chad Maniphest Tasks: T9897 Differential Revision: https://secure.phabricator.com/D14740
2015-12-11 16:07:45 +01:00
return '/phame/blog/view/'.$this->getID().'/';
}
public function getManageURI() {
return '/phame/blog/manage/'.$this->getID().'/';
}
public function getProfileImageURI() {
return $this->getProfileImageFile()->getBestURI();
}
public function attachProfileImageFile(PhabricatorFile $file) {
$this->profileImageFile = $file;
return $this;
}
public function getProfileImageFile() {
return $this->assertAttached($this->profileImageFile);
}
public function getHeaderImageURI() {
return $this->getHeaderImageFile()->getBestURI();
}
public function attachHeaderImageFile(PhabricatorFile $file) {
$this->headerImageFile = $file;
return $this;
}
public function getHeaderImageFile() {
return $this->assertAttached($this->headerImageFile);
}
/* -( PhabricatorPolicyInterface Implementation )-------------------------- */
public function getCapabilities() {
return array(
PhabricatorPolicyCapability::CAN_VIEW,
PhabricatorPolicyCapability::CAN_EDIT,
);
}
public function getPolicy($capability) {
switch ($capability) {
case PhabricatorPolicyCapability::CAN_VIEW:
return $this->getViewPolicy();
case PhabricatorPolicyCapability::CAN_EDIT:
return $this->getEditPolicy();
}
}
public function hasAutomaticCapability($capability, PhabricatorUser $user) {
$can_edit = PhabricatorPolicyCapability::CAN_EDIT;
switch ($capability) {
case PhabricatorPolicyCapability::CAN_VIEW:
// Users who can edit or post to a blog can always view it.
if (PhabricatorPolicyFilter::hasCapability($user, $this, $can_edit)) {
return true;
}
break;
}
return false;
}
public function describeAutomaticCapability($capability) {
switch ($capability) {
case PhabricatorPolicyCapability::CAN_VIEW:
return pht(
'Users who can edit a blog can always view it.');
}
return null;
}
/* -( PhabricatorMarkupInterface Implementation )-------------------------- */
public function getMarkupFieldKey($field) {
$content = $this->getMarkupText($field);
return PhabricatorMarkupEngine::digestRemarkupContent($this, $content);
}
public function newMarkupEngine($field) {
return PhabricatorMarkupEngine::newPhameMarkupEngine();
}
public function getMarkupText($field) {
return $this->getDescription();
}
public function didMarkupText(
$field,
$output,
PhutilMarkupEngine $engine) {
return $output;
}
public function shouldUseMarkupCache($field) {
return (bool)$this->getPHID();
}
/* -( PhabricatorDestructibleInterface )----------------------------------- */
public function destroyObjectPermanently(
PhabricatorDestructionEngine $engine) {
$this->openTransaction();
$posts = id(new PhamePostQuery())
->setViewer($engine->getViewer())
->withBlogPHIDs(array($this->getPHID()))
->execute();
foreach ($posts as $post) {
$engine->destroyObject($post);
}
$this->delete();
$this->saveTransaction();
}
/* -( PhabricatorApplicationTransactionInterface )------------------------- */
public function getApplicationTransactionEditor() {
return new PhameBlogEditor();
}
public function getApplicationTransactionTemplate() {
return new PhameBlogTransaction();
}
/* -( PhabricatorSubscribableInterface Implementation )-------------------- */
public function isAutomaticallySubscribed($phid) {
return false;
}
/* -( PhabricatorConduitResultInterface )---------------------------------- */
public function getFieldSpecificationsForConduit() {
return array(
id(new PhabricatorConduitSearchFieldSpecification())
->setKey('name')
->setType('string')
->setDescription(pht('The name of the blog.')),
id(new PhabricatorConduitSearchFieldSpecification())
->setKey('description')
->setType('string')
->setDescription(pht('Blog description.')),
id(new PhabricatorConduitSearchFieldSpecification())
->setKey('status')
->setType('string')
->setDescription(pht('Archived or active status.')),
);
}
public function getFieldValuesForConduit() {
return array(
'name' => $this->getName(),
'description' => $this->getDescription(),
'status' => $this->getStatus(),
);
}
public function getConduitSearchAttachments() {
return array();
}
/* -( PhabricatorFulltextInterface )--------------------------------------- */
public function newFulltextEngine() {
return new PhameBlogFulltextEngine();
}
/* -( PhabricatorFerretInterface )----------------------------------------- */
public function newFerretEngine() {
return new PhameBlogFerretEngine();
}
}