We scored our first kill today. @dgdfgdg slipped through our defenses in his initial volley, but we reacted quickly and the system automatically deflected his second salvo.

T11957 is the modern followup for this.

At least in this use case, I believe things turned out alright without this policy.

It's critical that we are addressing specific, plausible threat scenarios when implementing security protocols. This task currently lacks such a scenario.

This is pretty old and doesn't meet the requirements of a modern feature request (notably, clear definition of a root problem). Feel free to file a new request if this is still an issue. Particularly helpful would be discussion of why editing the page to say "Go see <other page>" is insufficient.

This got done at some point, I believe, since we have an SPF record now.

• Over time, we've drained the swamp to some degree on the default home page, by moving toward more useful defaults.
• We implemented Dashboards. Although we'd like to improve them, they've allowed ambitious users to fix this themselves for some time.
• See T11957 and M1473 for modern followups with a more concrete plan to lay this to rest.
• See also T11132 for discussion of NUX-oriented changes, specifically.

This is a billion years old now -- see, e.g., T11954 for more modern work.

"Blame Revision" was a freeform text field at Facebook (from before DiffCamp, even) where you were ideally supposed to enter the revision or commit that introduced the bug you're fixing, if you were fixing a bug introduced by some known change.

Which settings, in particular, are you seeing issues with? The correct answer is to fix them, not hack in something to work around them being broken.

the usecase is that if our administrator needs to change some configuration settings which may impact current login users, the idea is to perhaps have a mechanism for force a relogin so the setting takes affect. I accomplish by writing a cmdline application and querying the phabricator_session table to invalidate the user's session, it's not integrated into the phabricator UI, but work good enough for now.

@epriestley I can confirm it works fine both on Mac and Linux for me. Thanks a lot for the finding and quick fix!

That Chrome change seems at least plausible as a root cause to me, but I definitely don't know enough about the Chrome internals to really hazard a guess.

See also https://code.google.com/p/chromium/issues/detail?id=473657 for earlier adventures in Chrome.

Here's my upstream report:

Chromez

@chad was that for me or for Chrome? 😄

@epriestley could it be related to this change? https://chromium.googlesource.com/chromium/src/+/a67debf9a9b78f60e7b10b5574ae4ceab49af31b%5E%21/#F2

Here's my reduced test case for Chome 55:

Hah, I was on Chrome 54, and my report above works. But after updating to 55, it no longer works. Something changed in Chrome. Not sure what though.

@chad I was replying but saw now your last comments, thanks @epriestley for narrowing it down. Interesting that I can repro on Chrome 55/Mac while you can't.

Basically, I've found:

Oh, it reproduces for me.

This appears to be a bug in Chrome, because this fixes it:

This doesn't reproduce for me on this install in Chrome 55/Mac, or any other browser. I'm assuming the issue you saw on this server was T11998 which was a local configuration issue.

Specifically, I resolved it by just pushing everything.

I think I had pushed new code to secure001 and then wandered off to do something else.

Our expectation building Phabricator is that it's easy and obvious to accomplish tasks. Where are you looking in Dashboards that you're not seeing how to accomplish this?

Oh, I think the edit to the title here is actually misleading, and the author in this scenario never used "Request Review" (this action is only available if the author has previously used "Plan Changes", which they did not appear to in this scenario).

I have a not-so-bad version of this in mind but it seems that the printer faxers are too terrified of our advanced defenses to even attack us any more.

We have an identical ticket we plan to fix, definitely agree it's a bad experience.

Okay then, I thought this was a bug as it didn't seem to make sense for me as a user. Sorry for taking up your time.

This is expected behavior. We want to show an error instead of just vanishing the widget.

@rscircus - this task (like I assume most tasks here) needs paid prioritization to move forward. see https://secure.phabricator.com/w/prioritization/

• Systems integrated with Doorkeeper (JIRA, Asana, some prototype GitHub support) already get URIs marked up.
• The current JIRA integration does cover JIRA URIs in all remarkup systems, including Phriction and Maniphest, although you can not link to multiple JIRA installs until T6703, and you must use full URIs (if you use JIRA-123, it's possible that multiple linked installs have project namespaces called "JIRA"). It's possible we'll support this more naturally in the future, but not until after T6703, which is a very low priority.
• Custom markup rules already supported (see P1157, P1209 for some examples), although you're on your own to write them. These are probably the best fit for your use case.
• I believe needs for this sort of thing are often very specialized, so I do not currently plan to add any kind of generic, configurable remarkup rule that just matches arbitrary regexps against stuff and links them. You could write such a rule as an extension. One caveat to this is that we currently have bugtraq.url and bugtraq.logregex, which sort of work like this, except in a bad way. I'd like to remove them in the future, but there's an outside possibility that we'll replace them with a more flexible system like the one you describe.

Thanks!

Thanks! Yeah, this was just some editing/testing slop on my part. Your suggested fix is correct.

can admin set a dashboard as the defaut dashboard for everyone?

This issue was solved by updating to the latest everything. I apologize for the noise. :-(

Here's the same rule with test console:
https://secure.phabricator.com/herald/transcript/185171/

(We don't maintain two code paths for Herald / Test Console)

Please complete the bug report first.

The transcript you are pointing doesn't seem to be obtained using Test Console. Can you try using that?

I tried the following, specifically:

Please read Contributing Bug Reports and fill in all required information for a bug report. Thanks!

It seems, this task/problem has truly no priority, as @epriestley mentioned in his task description already. After skimming through related T5055, that idea reminded me of https://aur.archlinux.org/.

Yeah, seems to be a bug in Chrome. I would follow up with them. There is no correct means to style it in Ubuntu, just some hacks.

(Feel free to follow up with reproduction steps once you've sorted everything out)

You have to be up to date and you must provide reproduction information in order to file a bug report. Please use Ponder otherwise. Thanks!