rejetto forum

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - TEA-Time

Pages: 1 2 3 4 5
HTML & templates / Re: Admin Panel : Creating a proper admin panel.
« on: January 04, 2009, 11:45:05 PM »
Attachment updated... Everything works fine!  ;)

Where did the English go?? ;)

Oh... I figured it out!  Don't ask me how. Heh  I was looking through it and figured that if I "broke" the [special:strings] section that it might work, and it does!  I stuck [blah] in after that tag, but I'm sure the whole section could just be removed, too.

Very clever! :-)

Bug reports / Re: Permission problems in latest betas
« on: January 04, 2009, 09:51:46 AM »
Ooooops..... :-[  I just realized that this actually has to do with the templates I've been playing with. :-[

Thunderchicken of Glory

They import their own template folders and set the flags.  Color me embarrassed! :-[ (if you couldn't already tell. heh)  But I am learning! ;D

Anyway, of course it's still necessary for me to change the Access to the templates folder to allow "Anyone" for situations like this thread is about.

So after making this discovery, I checked the wiki and there doesn't appear to be a way using a macro to enable the "Anyone" permission in the Permissions/Access panel.  The same goes for the "Any account" and "Anonymous" permissions.  I would think these would be equally as important as the current ability to assign specific users.

HTML & templates / Re: Admin Panel : Creating a proper admin panel.
« on: January 04, 2009, 03:19:40 AM »
I'm sorry but if you read my first post:
You can see; that I am a complete n00b when it comes to programming of any kind, and the stages it took me to learn about macros.
I am still quite pleased that I managed to learn alot about macros/html and make this in only two days.
I hope I will be able to do things like this properly in the future but for now I am still learning.

No problem at all.  I was just curious.  I see from mars' version that it is possible to do it in one step, so now we both know. ;)

This does indeed disable the account but the line I use is not
Code: [Select]
{.set account|{.^accountname.}|enabled=true.}it is:
Code: [Select]
{.set account|{.^accountname.}|enabled={.^accountstatus.}.}
Are you sure you are editing the:[statuschange] section and not the:[newusermake] section?

You missed the part where I said I changed the command after an account is created as a test. ;)  It still didn't disable the account, but mars explained that the field actually needs to be blank rather than "false".

The typo is my bad though.

That's ok.  Since the field actually needs to be blank to disable, it needs reworded anyway. ;)

I will hopefully make a newer version later on - probably based on Mars' one in the post above :D

Looking forward to it!

HTML & templates / Re: Admin Panel : Creating a proper admin panel.
« on: January 03, 2009, 08:07:57 PM »
(using beta build 218)

Disabling accounts doesn't work for me either.  In fact, if I disable an account from inside HFS and then go through the motions of trying to disable it (again) through Admin Panel, it actually gets re-enabled. :-\  Is this maybe a bug in HFS?

The bulk of the contents of template files is still a mystery to me, but I *think* I manged to change the command after a new account is created to set it to be disabled as a test, but it still ends up enabled.  Here is what I changed:

{.set account|{.^accountname.}|enabled=true.}


{.set account|{.^accountname.}|enabled=false.}


Also, I believe there is a typo in the following line.  In the parenthesis after "false", shouldn't it be "without quotes" instead of "with quotes"?

Then type "true" (without quotes, to enable) or "false" (with quotes, to disable), click submit then click Change.

And finally, I'm afraid I have to ask.  Why is it necessary to click two things to invoke a change?  Isn't it possible to do these things in one step using variables instead of two with intermediate .txt files?

Bug reports / Upload permission inheriting
« on: January 03, 2009, 08:27:16 AM »
Hi rejetto,

Sorry, don't mean to complain twice in one day, but I think I found another bug or two. :P

Using beta build 218, but I don't know when this problem started or if it's always been there because I've never tried it before.

I have Upload permission set to "Any account" for the root, which is bound to a real folder.  Inside HFS, tooltips for real subfolders say "Upload allowed for: @any account [inherited]".  But when going into that subfolder in a browser, the Upload option is not available as expected, unless I specifically set it for that subfolder.

Strangely, virtual subfolders and even files also say "Upload allowed for: @any account [inherited]", which doesn't make sense.  You're only supposed to be able to upload to real folders, right?

And finally, if I unbind the root from the real folder where I'd previously allowed uploading, the subfolders (real and virtual) and files' tooltips still say "Upload allowed for: @any account [inherited]", even though there's no way to edit that permission with the root now being virtual.  I would think that with the root being virtual, that "ghost" permission shouldn't even exist for something below to inherit.

Any questions or want me to try something?  Just ask. :)

Bug reports / Re: Permission problems in latest betas
« on: January 03, 2009, 05:58:29 AM »
Hi rejetto,

Sorry to have to dig this bug back up!

I'm using beta build 218 now.  You might want to skim through the previous messages if you need a refresher on what the problem was. ;)

I ran into this problem again using a customized template.  I was using the built-in/default template before and that continues to work.  I just never tried it while using a customized template until now.

The problem appears to be in the way the template folder inherits its permissions from the root.  I can "fix" it by changing the template folder's permissions to give access to "Anyone".  This also allows access by an account that only has permission to folders other than the root, like the situation we worked on before.  Also, doing this allows the template to be used when no anonymous access is given and someone does not successfully log in, by allowing the "Unauthorized" page to look like it's supposed to.

So, I have two questions...

1) Are there any security risks using this "fix"?  I don't know why there would be, but you know a lot more about how things work than I do. ;)

2) If this actually is the proper way to fix this, could you make it so that permission is automatically assigned to the template folder when a customized template is assigned?

Of course, if you have any questions, feel free to ask!

HTML & templates / Re: Admin Panel : Creating a proper admin panel.
« on: January 03, 2009, 12:50:23 AM »
Hi Ryan,

Sounds really cool, but I get a 0 byte Zip file when I try to download it.

I tried your modded TCOG template, but I don't know how to get to the admin panel without the docs in the Zip file. ;)

Edit: Aha!  I figured out how to get to the ~adminpanel. ;D

Bug reports / Re: No-IP update error in 2.3 beta Build 203
« on: September 25, 2008, 07:58:18 PM »
Hi rejetto,

No-IP changed something and now it's working again.  They are returning just a single line now for the URL in my first post, for example:


Bug reports / Re: No-IP update error in 2.3 beta Build 203
« on: September 19, 2008, 05:47:09 PM »
Ok, thanks rejetto! :)

Bug reports / Re: No-IP update error in 2.3 beta Build 203
« on: September 19, 2008, 04:53:13 PM »

I know you're just trying to help, but that's not what I'm looking for.  I know I only have 16 posts here on this board, but I'm an extremely capable person.  I found a problem with the URL that HFS builds and that's why I posted here in the "Bug reports" forum.  The rest of the information I provided is from the troubleshooting that I did in order to find out what's being sent and what's being returned in hopes that it'll help in solving the problem.  As is obvious in my first post, HFS' log doesn't show the full text of what No-IP returns, and that's why I used my browser.


Are you saying that using the No-IP wizard should fix the problem?  I've tried that and the URL in my first post is what gets built.

Bug reports / Re: No-IP update error in 2.3 beta Build 203
« on: September 19, 2008, 07:20:32 AM »

Your no-ip custom DNS updater code looks wrong.  It should be the following which works fine here.

Code: [Select]
username=email address
host=no-ip hostname

Whatever it's supposed to be, the URL that I got from the Custom field is what HFS builds when using the No-IP wizard, hence the reason I reported the problem.

Bye the way, you don't put that code in your browser.  HFS uses it when updating the dynamic dns.

Yes.. I know this.  I also know that it's possible to put it into a browser to see what's returned, and it's possible to copy & paste from there, whereas that can't be done from the "Dynamic DNS updater -> See last server response" dialog.

If it still isn't working for you, go to no-ip and set up another host name.

I shouldn't have to.  It's been working fine up until now.  Besides, compared to your URL example, it now appears as though it's HFS that is building the URL incorrectly.

But thanks for trying.

Bug reports / No-IP update error in 2.3 beta Build 203
« on: September 19, 2008, 05:14:56 AM »
Hi rejetto,

I'm not sure if this is a problem with this build or if No-IP changed something, but I just noticed I'm receiving this error when the dynamic DNS updater runs (sensitive info removed):

9/18/2008 9:35:12 PM DNS update requested for unknown reply: 10

No-IP has my current IP registered, but I'm not sure if it's from before the error started occurring or if it actually is working and just their response has changed.

In case it helps, the Custom field has this URL:

Code: [Select]
And the following is returned if I put that URL into my browser (with my IP in place of the macro, of course):


Unfortunately, I'm not sure how things look when they are working, but you probably do. ;)


Beta / Re: Testing build #202
« on: September 09, 2008, 05:45:13 PM »
Hi rejetto,

- the problem addressed in build #199 is now solved also with regular folder pages

Looks good now! ;D


Bug reports / Re: Permission problems in latest betas
« on: September 08, 2008, 05:11:34 PM »
When you give access to user A to the root, he has access to the folders also.
So permissions are inherited.
When you defining access rights for a folder, why should HFS always give access to A ?
You'll likely have a scenario like:
- home/root access allowed for by A and B
- folder under root allowed to B only

Just like we're dealing with here. ;)

I understand that it will be better to have a dialog where you select accounts for the folder, with A and B already selected, and you remove access for A. Much handier. That's how will be in the future.
Meanwhile you are supposed to give appropriate rights manually.

Excellent.  That will work, too.

.........This been said, the problem persists: you can give strange access rights about the root and the folder, and we can suppose you don't want anything to be left out to the public, since we even protected the root.

I had an hard time finding a solution but, perhaps, i did!

if you ask for a folder you have access rights to, then all other files the browser will require from the root will report your folder as referrer.
Then, the root is protected and you don't want anyone to mess around, right?
But we can suppose it's not a big deal if who has access to the folder will access the template sections who appears like files in the root. He will not have access to the root files, but only to sections.

logic: if you have no access for this request, and the request starts with /~ABC, and ABC is a template section, then we'll recheck your access rights against the referring folder (where you are supposed to have sufficient rights).

Ah.. that sounds like a great solution.  Good job!

SO! It should be ok since next beta build.

Looking forward to it! ;D

Bug reports / Re: Permission problems in latest betas
« on: September 07, 2008, 08:24:22 AM »
Hi rejetto

Thanks for continuing to look into this!

A friend and I were thinking that it would make sense to be able to give admin type users access to the root and they would automatically be able to browse down through the VFS structure.  Then give restricted users access only to specific lower folders.

Except we actually ran into two problems with trying to do that.

1) The problem you and I are discussing here

2) Permissions given to the root don't automatically flow down (not inherited) if specific permissions are given to lower folders.  It would be cool if there was an option that would allow that if desired, but of course it would be off by default so as not to suddenly change the permission structure of people's existing HFS setups.

I know #2 is actually a request, but I mention it here because it's necessary for what we'd like to be able to do.  If you want, I can add it to the main board, which I guess is where requests/suggestions go..?

Edit: Can't the CSS templates come from the same place the HTML templates do?

Pages: 1 2 3 4 5