Login | Register
My pages Projects Community openCollabNet

Discussions > dev > Re: [Patch] 2/5: multichan

Project highlights: Stable Version: 1.6.1, Development Version: 1.7.6

Discussion topic

2020-03-13: This site is going to be decommissioned and shut down very soon. Please copy and archive any data you wish to keep ASAP

Back to topic list

Re: [Patch] 2/5: multichan


Author theslack
Full name Jack Neely
Date 2005-02-09 13:08:45 PST
Message On Thu, 03 Feb 2005 22:12:14 -0500, Hunter Matthews <hunterm at tigris dot org> wrote:
> Also keep in mind that ConstructParser was a bit of a hack we had to
> have because we had no client database. As soon as we have a client
> database, we can ditch construct parser.

At first I thought how the hell do I ditch constructparser in favor of
the DB and still be able to parse that particular header. Well,
hell...the header is parsed, the data shoved into
SysHeaders.data['X-R​HN-Auth-Channels'] and is only exposed via
SysHeaders.getAuthChannels() which is actually never called. That
header data is only used in calculating the checksum.

Any place where we actually check what channels the client is
supscribed to is by doing this:

channels = db.db.getCompatibleC​hannels(si.getattr('​architecture'),
channels = auth.authorize.getAu​thorizedChannels(si,​ channels)

We all know that auth.authorize.getAu​thorizedChannels() just returns
the channels var.

In summary, I can rip it out now.

> What?
> Simple - In days of yore I looked at that header and said "That looks
> like what happens when you print a list of lists from python" - we'll
> parse that list and know which channels you're authenticated for. Early
> pre 1.0 versions did the quick but scary "eval()". RHN itself never
> parsed the sucker at all - it used this and a couple of other headers
> plus a hash to make sure the client hadn't tampered with anything, but
> to actually figure out which channels client N was subscribed to, it did
> a lookup against its database.
> At some point the RHN people made this header something that eval()
> can't handle. And ConstructParser was meant to be a safe eval().

My only thought is that I don't know when this change happened and I
don't particularly want to lose support for those older clients. But,
who cares if I don;t need to touch that header anyway?

> Jack,
> At this point, ConstructParser probably makes no sense - write a
> smaller (simpler) parser and plug it in.

To unsubscribe, e-mail: dev-unsubscribe@curr​ent.tigris.org
For additional commands, e-mail: dev-help at current dot tigris dot org

« Previous message in topic | 6 of 7 | Next message in topic »


Show all messages in topic

[Patch] 2/5: multichan Pauline Middelink <middelink at polyware dot nl> Pauline Middelink <middelink at polyware dot nl> 2005-01-10 12:23:47 PST
     Re: [Patch] 2/5: multichan Jack Neely <jjneely at pams dot ncsu dot edu> Jack Neely <jjneely at pams dot ncsu dot edu> 2005-01-17 15:18:41 PST
         Re: [Patch] 2/5: multichan Pauline Middelink <middelink at polyware dot nl> Pauline Middelink <middelink at polyware dot nl> 2005-01-18 02:21:07 PST
             Re: [Patch] 2/5: multichan theslack Jack Neely 2005-01-19 19:08:59 PST
                 Re: [Patch] 2/5: multichan hunterm Hunter Matthews 2005-02-03 19:12:14 PST
                     Re: [Patch] 2/5: multichan theslack Jack Neely 2005-02-09 13:08:45 PST
                         Re: [Patch] 2/5: multichan theslack Jack Neely 2005-02-20 17:58:07 PST
Messages per page: