Hello, Mark,

This action solved the stated problem but now I note that the same situation pertains in "Tend to pending moderator requests" where held messages cannot be read or actioned.

Also "Go to list archives". (we do not have this running). The other two links are fine.

I see three more 'absolute=1' entries in admindb.py - shall I change all three?

regards Anne

On Wed, Apr 10, 2013 at 03:00:50PM -0700, Mark Sapiro wrote:

Mark Sapiro wrote:

...

What we need to do is figure out why those few URLs on the Membership List page are absolute. It may be a bug. I'll look at that.

There are two places in Mailman/Cgi/admin.py where it requests absolute URLs. The relevant code bits are

def membership_options(mlist, subcat, cgidata, doc, form): # Show the main stuff adminurl = mlist.GetScriptURL('admin', absolute=1) ...

and

def password_inputs(mlist): adminurl = mlist.GetScriptURL('admin', absolute=1)

The first of these affects the 'letter/digit' links on the membership ant the action for the Search, Submit Your Changes and Set buttons, and the second affects (I think) only the link to the general options section on the Passwords page.

I see no reason why these need to be absolute URLs. You could just change the two mlist.GetScriptURL lines to

adminurl = mlist.GetScriptURL('admin')

and I think that would fix it. If you wouldn't mind trying this and reporting, I'd appreciate it and if it seems OK, I'll file a bug and change it for 2.1.16.

There may be some http/https issue around this, but offhand, I can't think why.

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

Anne Wainwright wrote:

Actually there were 5 'absolute=1' entries in admindb.py and changing them all has resolved the issue of pending moderator request, but the list archives remains absolute.

Current Mailman has only 4. The change between 2.1.14 and 2.1.15 to add the logout button inserted this one

    # Now print the results and we're done.  Short circuit for when

there # are no pending requests, but be sure to save the results! admindburl = mlist.GetScriptURL('admindb', absolute=1) if not mlist.NumRequestsPending():

and removed these two

        doc.AddItem(_('There are no pending requests.'))
        doc.AddItem(' ')
        doc.AddItem(Link(mlist.GetScriptURL('admindb', absolute=1),
                         _('Click here to reload this page.')))
        doc.AddItem(mlist.GetMailmanFooter())
        print doc.Format()
        mlist.Save()
        return

    admindburl = mlist.GetScriptURL('admindb', absolute=1)
    form = Form(admindburl)
    # Add the instructions template

In any case, you want to remove ', absolute=1' from the two or its one replacement.

That leaves these three:

in main()

    # Add a link back to the overview, if we're not viewing the

overview! adminurl = mlist.GetScriptURL('admin', absolute=1)

in handle_no_list()

url = Utils.ScriptURL('admin', absolute=1)
link = Link(url, _('list of available mailing lists.')).Format()
doc.AddItem(_('You must specify a list name.  Here is the

%(link)s'))

and in show_helds_overview)_

# Add the by-sender overview tables
admindburl = mlist.GetScriptURL('admindb', absolute=1)

The last of these should definitely be changed. The other two are actually links back to the admin (not admindb) overview page. The one in main() is a link to the admin overview for the host of the list that we're currently processing in the admindb page, but the one in handle_no_list() is different because there is no list. Depending of site configuration, the host in this URL if absolute may be the web host of the current page, or it may be DEFAULT_URL_HOST. This could cause problems with a relative URL if the absolute one should go to DEFAULT_URL_HOST.

So I would say in your case, you can probably safely remove them all, but in terms of what I might do for a bug and fix, I may not do the one in handle_no_list().

As far as the archive URL is concerned, this is generated differently as it has to take into account whether the archives are public or private and the setting for PUBLIC_ARCHIVE_URL and it's always absolute.

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

Hello, Mark.

I have tried that with partial success, but there is another odd unmentioned behaviour that I have/had to cope with.

When I click on a 0-9A-Z link I am dumped outside back at the login window. When I log in a second time I am presented with the list of members that I wanted in the first place, subsequent queries work first time. Similarly when I need to moderate a message.

I am not sure under what exact conditions this happens, even if it is consistent across the 3 machines that could be used. So will try and determine a consistent set of circumstances under which this occurs.

At the moment removing the 'absolute=1' entries does the job 100%.

Anne

On Fri, Apr 12, 2013 at 01:35:34PM -0700, Mark Sapiro wrote:

Mark Sapiro wrote:

...

So I would say in your case, you can probably safely remove them all, but in terms of what I might do for a bug and fix, I may not do the one in handle_no_list().

I was going to file a bug and 'fix' this, but I have instead asked a question on mailman-developers. See <http://mail.python.org/pipermail/mailman-developers/2013-April/022761.html> for that post and what I'm concerned about.

In the mean time, it occurred to me that possibly you could fix this without changing Mailman simply by putting an appropriate entry in /etc/hosts on your 'inside the lan' work station.

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

Hi, Mark,

read below.

On Sun, Apr 14, 2013 at 04:14:32PM -0700, Mark Sapiro wrote:

On 4/14/2013 10:13 AM, Anne Wainwright wrote:

...

I have tried that with partial success, but there is another odd unmentioned behaviour that I have/had to cope with.

When I click on a 0-9A-Z link I am dumped outside back at the login window. When I log in a second time I am presented with the list of members that I wanted in the first place, subsequent queries work first time. Similarly when I need to moderate a message.

If I understand correctly, this is what's happening in those cases. You have a /etc/hosts or whatever to direct the 'outside' host to the 'inside' host. You go to the admin or admindb page via an 'inside' URL (probably a bookmark) and log in. Once there, relative links work fine. You go to a link with an absolute URL. This points to the 'outside' host which as far as your browser is concerned is not the host that set the authentication cookie so it is not returned to the 'outside' host and you have to log in again. Once you have logged in once for each host, you are authenticated for the rest of the browser session.

The answer is if you have /etc/hosts or whatever routing the 'outside' host to the 'inside' host, never go to the 'inside' host (fix your bookmarks to point to the 'outside' host name).

I had attacked this by a circuitous route, putting the ip address in the bookmark because I did not have an entry in /etc/hosts. When I got to putting an entry in /etc/hosts I did not change the bookmark. So ...

Yes, that is totally correct. I am leaving it like that for the moment to ensure there are no issues, and I can modify my FAQ 4.88 to reflect this. Whatever else, for any one implementing a relay server it seems the best way rather than have them editing away at key coding files.

...

At the moment removing the 'absolute=1' entries does the job 100%.

If you do notice any issues related to this, please let me know.

I will return to this configuration in a short while and will report on any issues or lack thereof.

thanks for all the time taken

Anne

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On 05/01/2014 11:31 AM, Anne Wainwright wrote:

I still have dyndns addresses showing on the numeric/alpha address listing both locally and from outside

I do not understand "the numeric/alpha address listing"

Where specifically do you see these?

I have changed DEFAULT_URL_HOST in mm_cfg.py appropriately, cleared the browser caches. Where can this be dyndns be hiding, or is it time to run the fix_url script?

Probably. See the FAQ at <http://wiki.list.org/x/mIA9>.

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

if this is a duplicate, my error, don't see my post anywhere. see below

On Thu, May 01, 2014 at 05:19:35PM -0700, Mark Sapiro wrote:

On 05/01/2014 11:31 AM, Anne Wainwright wrote:

...

I still have dyndns addresses showing on the numeric/alpha address listing both locally and from outside

I do not understand "the numeric/alpha address listing" The 0-9A-Z table of members under Membership Management - sorry if unclear.

Where specifically do you see these?

...

I have changed DEFAULT_URL_HOST in mm_cfg.py appropriately, cleared the browser caches. Where can this be dyndns be hiding, or is it time to run the fix_url script?

Probably. See the FAQ at <http://wiki.list.org/x/mIA9>.

This did however resolve the issue

with thanks Anne

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/anotheranne%40fables.c...