Apache Allura / Chat

Apache Allura / Chat is hosted on FreeNode IRC channel #allura

Log for 2013-10-03

  • 18:54:57
    ASFBot

    Allura/363: #363 started building, estimated 11 minutes left. https://builds.apache.org/job/allura/363/

  • 18:55:47
    brondsem

    cory_fu: did you end up committing that performance script to git? did you make a subdir for it?

  • 18:56:29
    brondsem

    just read https://sourceforge.net/p/allura/tickets/6734/#11b2 and was thinking that'd be good to go into a perf subdir too

  • 18:56:52
    cory_fu

    Yes, and yes. It should be in the ticket branch (which hasn't been merged yet). scripts/perf/

  • 18:58:01
    cory_fu

    Ugh

  • 18:58:14
    cory_fu

    So, as I was saying... +1 to grouping more scripts under scripts/perf

  • 18:59:17
    brondsem

    :)

  • 19:03:46
    tvansteenburgh

    hm, just saw this

  • 19:03:55
    ASFBot

    Allura/363: #363 built successfully after 8 minutes https://builds.apache.org/job/allura/363/

  • 19:29:58
    allura-ci-sf

    Project allura-rat build #156: FAILURE in 5.8 sec: http://jenkins.sdot.me/job/allura-rat/156/

  • 19:31:54
    brondsem

    [rat:report] Unapproved licenses:

  • 19:31:54
    brondsem

    [rat:report]

  • 19:31:54
    brondsem

    [rat:report] /var/lib/jenkins/workspace/allura/Allura/allura/scripts/md_perf.py

  • 19:34:49
    tvansteenburgh

    doh

  • 19:53:03
    ASFBot

    Allura/364: #364 started building, estimated 10 minutes left. https://builds.apache.org/job/allura/364/

  • 19:53:03
    ASFBot

    tvansteenburgh: [6734] Add license header

  • 19:59:24
    cory_fu

    tvansteenburgh: Getting a failure on [#6733]

  • 19:59:27
    cory_fu

    FAIL: allura.tests.test_security:TestSecurity.test_weird_allow_vs_deny

  • 19:59:27
    cory_fu

    vim +116 allura/tests/test_security.py # test_weird_allow_vs_deny

  • 19:59:45
    cory_fu

    But I think that's testing strange behavior that's not compatible with the block user feature anyway, so we should probably just remove that case.

  • 19:59:52
    cory_fu

    If you concur, I can go ahead and remove it

  • 20:00:50
    brondsem

    i think we should keep it

  • 20:00:52
    tvansteenburgh

    strange, i ran the whole suite and didn't get any failures

  • 20:00:59
    ASFBot

    Allura/364: #364 built successfully after 7 minutes https://builds.apache.org/job/allura/364/

  • 20:01:07
    cory_fu

    I just ran test_security.py

  • 20:01:09
    brondsem

    isn't it testing the weird behavior aside from the "block user" bit?

  • 20:01:48
    cory_fu

    That test is for strange corner cases of DENY behavior that I didn't think made any sense, so I fully expect them to gradually start failing as we make the permissions behave in a more reasonable way

  • 20:02:10
    cory_fu

    I'm not saying to remove the whole test, just that one case

  • 20:02:40
    brondsem

    ok, i'm fine with a small removal

  • 20:02:43
    cory_fu

    The particular case involves adding a DENY for *authenticated

  • 20:02:51
    cory_fu

    Which isn't possible via the UI

  • 20:03:15
    brondsem

    just want to keep the bulk of that test so it's there for [#6715]

  • 20:03:31
    cory_fu

    And is asserting that, even with DENY READ auth, if anon still has ALLOW READ, then authenticated should be able to read

  • 20:03:36
    cory_fu

    Which is dumb

  • 20:03:55
    brondsem

    well, that's the weirdness that is there :)

  • 20:04:30
    cory_fu

    I could invert the case so that we actually start testing for the sane behavior to ensure it doesn't break when we change the block user implementation

  • 20:04:42
    cory_fu

    But then it doesn't really belong in the "weird" test case any more

  • 20:05:03
    tvansteenburgh

    well the failure makes sense because of what i changed

  • 20:05:08
    cory_fu

    Yeah

  • 20:07:08
    tvansteenburgh

    i would invert the case i think

  • 20:07:29
    cory_fu

    Actually, reading the rest of the test, maybe the whole thing needs to be changed,

  • 20:08:48
    cory_fu

    Yeah, the new block user changed the entire behavior of that case. I'll invert it and update the comments

  • 20:16:13
    allura-ci-sf

    Yippie, build fixed!

  • 20:16:14
    allura-ci-sf

    Project allura-rat build #157: FIXED in 2.6 sec: http://jenkins.sdot.me/job/allura-rat/157/

  • 20:19:27
    brondsem

    cory_fu: for [#6668] word from our ops team is that we need to have the force_ssl.pattern option, at least for now

  • 20:19:53
    brondsem

    so i'm going to see about merging both options

  • 20:20:04
    cory_fu

    I don't like it

  • 20:20:23
    brondsem

    those are the requirements we have to work with

  • 20:20:32
    brondsem

    make just one page under SSL for now

  • 20:21:34
    brondsem

    i don't want to wait weeks or more until we're ready for the respect-ssl or always-ssl options

  • 20:22:05
    brondsem

    but we could put those options into Allura now so they're available for anyone to use

  • 20:25:09
    cory_fu

    Yeah

  • 20:25:45
    cory_fu

    It'll just make the code ugly.

  • 20:26:30
    brondsem

    yeah, little bit. but it's a reasonably useful feature to have in general I think

  • 20:26:32
    cory_fu

    And split the handling of the SSL. Also, be careful how you merge the force-ssl with the respect-ssl for the login overlay; there's potential for a redirect loop there

  • 20:26:40
    brondsem

    we do need to get rid of that SFUSER bit

  • 20:26:43
    cory_fu

    Yes

  • 20:27:25
    cory_fu

    Maybe add an is_authenticated() method in the AuthProvider?

  • 20:27:47
    brondsem

    yeah, or even checking the session cookie that allura itself creates

  • 20:28:06
    brondsem

    i'll have to play around with it I guess

  • 20:30:05
    cory_fu
  • 20:30:15
    cory_fu
  • 20:30:28
    cory_fu

    It seems that all_allowed() is not respecting the blocked user feature

  • 20:31:56
    cory_fu

    That only seems to be used in the Private ticket feature, currently, but it could cause switching a ticket to Private and/or back could allow blocked users access.

  • 20:32:16
    cory_fu

    It might not, though, because you can't block the named role Developer

  • 20:32:42
    brondsem

    yeah, all_allowed probably wasn't updated to match the logic

  • 20:32:42
    cory_fu

    Should I commit the test change and send it back?

  • 20:32:49
    cory_fu

    Or just not worry about it

  • 20:33:01
    cory_fu

    (And comment out that assertion)

  • 20:33:11
    brondsem

    might be ok for now as long as we fix it when we change has_access later?

  • 20:33:38
    cory_fu

    If we remember to uncomment that line from the test

  • 20:33:46
    cory_fu

    I can make a note on the ticket

  • 20:33:51
    brondsem

    too late

  • 20:33:52
    brondsem

    already on it

  • 20:33:54
    cory_fu

    lol

  • 20:34:08
    cory_fu

    Ok, so I'll comment out the assert and merge this, then

  • 20:34:13
    brondsem

    ticket already references that test

  • 20:34:17
    brondsem

    now references all_allowed too

  • 20:34:20
    cory_fu

    You two ok with the rest of the changes to taht test?

  • 20:34:26
    cory_fu

    Cool

  • 20:34:57
    brondsem

    sure whatev

  • 20:35:43
    cory_fu

    lol

  • 20:45:12
    tvansteenburgh

    sorry, just saw this

  • 20:48:52
    ASFBot

    Allura/365: #365 started building, estimated 9 minutes left. https://builds.apache.org/job/allura/365/

  • 21:01:12
    ASFBot

    Allura/365: #365 built successfully after 12 minutes https://builds.apache.org/job/allura/365/

  • 21:04:19
    brondsem

    cory_fu: i was thinking about how to make the force ssl configuration be an option

  • 21:04:31
    brondsem

    realized you can do it with no code, just using force_ssl.pattern = .

  • 21:04:34
    brondsem

    thoughts?

  • 21:12:49
    cory_fu

    Yeah, that would work. Not obvious, though

  • 21:13:06
    cory_fu

    But not terrible, either, I suppose

  • 21:14:15
    brondsem

    i'll put an example in the .ini file

  • 21:14:22
    brondsem

    just as obvious then as any other config entry there

  • 21:19:13
    cory_fu

    I won't argue that

  • 21:22:26
    brondsem

    and i'm going to defer the extraction of SFUSER

  • 21:22:50
    brondsem

    i can't figure out how to access the session vars from that middleware

  • 21:23:16
    brondsem

    and the SFUSER check has a subtle side benefit (which I'll comment in the code) of letting all non-SF allura setups run without ssl

  • 21:23:23
    brondsem

    which is important for local development

  • 21:29:12
    brondsem

    ACTION is not thrilled that there are no unit tests for allura/lib/custom_middleware.py at all

  • 21:37:18
    ASFBot

    Allura/366: #366 started building, estimated 9 minutes left. https://builds.apache.org/job/allura/366/

  • 21:37:18
    ASFBot

    dbrondsema: [6668] Fixed importer login overlay not working due to SSL restrictions

  • 21:37:18
    ASFBot

    dbrondsema: [6668] additional notes about forcing ssl

  • 21:48:04
    ASFBot

    Allura/366: #366 built successfully after 10 minutes https://builds.apache.org/job/allura/366/

  • 22:40:11
    ASFBot

    Allura/367: #367 started building, estimated 10 minutes left. https://builds.apache.org/job/allura/367/

  • 22:40:11
    ASFBot

    dbrondsema: [6706] Added config to hide importers from table without disabling them

  • 22:50:19
    ASFBot

    Allura/367: #367 built successfully after 10 minutes https://builds.apache.org/job/allura/367/