rejetto forum
Software => HFS ~ HTTP File Server => Programmers corner => Topic started by: Mars on April 08, 2009, 12:45:42 AM
-
Since the extension of the call of sections through the url /~section, it is possible to obtain certain not wished effects
All the sections are accessible since the url http://ip:port/~section
To prevent that certain sections are visible by url, but available by a call with a macro {.$name.}, here is what I propose:
[name| no log | private ] ('no log' is optionnal).
classelib.pas
TtplSection = record
name, txt: string;
nolog: boolean;
nourl: boolean; //add by mars
end;
......
procedure saveInSection();
....
// there may be flags after |
s:=cur_section;
cur_section:=chop('|', s);
ss:=split('|', s); //add by mars
for i:=0 to length(ss)-1 do ss:=trim(ss); //add by mars
base.nolog:=idxOf('no log', ss) >= 0; //add by mars
base.nourl:=(ansiPos('private', s) > 0)or(ansiPos('protect', s) > 0); //add by mars
// base.nolog:=ansiPos('no log', s) > 0;
// there may be several section names separated by =
.....
main.pas
....
// provide access to any [section] in the tpl, included [progress]
if data.urlvars.values['mode'] = 'section' then
s:=or_(data.urlvars.values['id'], 'no-id') // no way, you must specify the id
else if (f = rootFile) and (urlCmd > '') then
s:=copy(urlCmd,2,MAXINT)
else
s:='';
if (s > '') and tpl.sectionExist(s)
and not tpl.getSection(s).nourl //add by mars
then // section [] is not accessible
begin
getPage(s, data);
exit;
end;
// from here on, we manage only services with no urlCmd.
.....
All the sections referenced in a template by one /~name shall not have to be private at the risk of inaccessibility as this example:
<link rel="stylesheet" href="/~style.css" type="text/css">
<link rel="stylesheet" href="/~style.menu.css" type="text/css">
<frame name='progress' src="/~progress" scrolling='auto' marginwidth='0'>
and more ...
-
yes, i think we need something like this...
not sure "private" is the best name, but i have no better idea at the moment :)
-
To solve this question till now I used a flag (entryok) set in the sections that were allowed to call from url (...~section) and the existence of this flag is tested in the remaining sections and their execution is excluded if flag is not set.
I think it would be less work to mark the 'public' sections [error:public], [Upload:public] etc. and to disallow by default al url access to sections that are not marked as public. (some basic sections like 'error', 'upload' could be public by default).
-
i guess your suggestion would be good, if it was just backward compatible, but it isn't.
some templates would stop working.
-
In both cases it's better to return to the former(ancient) system of the visible sections only if their name begin with a 'sym-'. ;)
It was the beautiful period when everything was simpler :D
The question put by rejetto is only to know what is the best name to be used:
private, protect, restrict ......
Make your sets... ;D
-
1. It is needed to establish if we want to delare restricted sections marking them with mars's proposal as private, restricted or whatever, or , as normally there are fewer sections that we need to access with url~section than the rest of sections, to explicitly allow access to this few sections.
2. The compatibility problem could be avoided with a new macro, normally to be placed in the special:begin section, something in the following form:
{.publicsection | upload error ..... .}
{.if|%user%|{.publicsection | chat admin ..... .}
I think there is no doubt how it should work when the macro is defined. But it remains to decide, if in the absence of the macro, all sections should be handled as public (not restricted) to allow compatibility with existing templates, or to set a new option in the template menu: restricted sections on/off (default off).
As this would be a very special macro (no to be used inside other macros nor manipulated as other macros), we could also think in a [special:(public)sections] thing.
Both ways should allow to use the {.if.} statement, for example to have public error, but {.if|%user%|{.allow|upload.}.} or {if |=|%user%|admin|{.allow|admin chat ..}.}
-
i know most sections are not planned to be accessible via URL,
but how often this is a real problem?
i think very few.
if these are rare as i think, it should not be a problem to specify the new attribute.
-
There are really very few things that need to be accessed from url~section.
Indeed, everytime before thinking we need such a new section with url access, we should see if we can not obtain the same result creating a link to a folder (optionally with ?param ) containing a diff template to obtain the desired result.
so the 'allow-list' would be very short !
-
Dear bacter, try to think about the subject by taking another way of reflection, and you will see certainly that more things are certainly possible, otherwise we shall infinitely walk round and round
It is just a proposition ;)
-
so the 'allow-list' would be very short !
i already asserted this, but that doesn't answer my question.
-
one programmer question
in a template, is it possible to differentiate <img src="127.0.0.1/~img_folder"> of an url request as 'http://127.0.0.1/~img_folder' ?
-
i didn't understand :-X
-
hfs can deserve a request with <img src="127.0.0.1/~img_folder"> can bee deserved but not
Hfs he can make the difference between the access for a resource from a request of the type <img src="127.0.0.1/~img_folder">, and a simple request by the URL line 'http://127.0.0.1/~img_folder' in the browser?
then <link rel="stylesheet" href="/~style.css" type="text/css"> is allowed to access the section [style.css|private]
but a direct URL request http://ip:port/~style.css is not allowed
-
most times you can tell by the content of conn.getHeader('Referer')
but it's not very reliable.
what you get by doing this?
-
I notice one difference into the header with <img src="/~img24"> and <a href="/~img24">click</a> and URL http://127.0.0.1/~img24
internal request: <img src="/~img24">
GET /~img24 HTTP/1.1
> Accept: */*
> Referer: http://127.0.0.1/
link request: <a href="/~img24">click</a>
> GET /~img24 HTTP/1.1
> Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, application/xaml+xml, application/vnd.ms-xpsdocument, application/x-ms-xbap, application/x-ms-application, */*
> Referer: http://127.0.0.1/
URL request: http://127.0.0.1/~img24
> GET /~style.css HTTP/1.1
> Accept: */*
there is no referer defined here.
this allow some permissions for sections
[mysection|no log|no url|no link]
with 'no url' a user can't access to the section by http://.../~mysection
with 'no link' a user can't access to the section by <a href="http://.../~mysection"></a>
but other <balise src=/~mysection> or <link href=/~mysection> are always allowed
I found the answer to what I wanted to set up in term of protection for sections, I shall propose a modification of the code in this direction
please wait before posting the next build, thanks!
Posted on: 13 April 2009, 02:33:08
classelib.pas
TtplSection = record
name, txt: string;
nolog, nourl, nolink: boolean; //mod by mars
end;
.....
cur_section:=chop('|', s);
base.nolog:=ansiPos('no log', s) > 0;
base.nourl:=ansiPos('no url', s) > 0;
base.nolink:=ansiPos('no link', s) > 0; // there may be several section names separated by =
main.pas
// NB: section [] is not accessible, because of the s>'' test
section:=getsection(s);
if assigned(section)
and not(
section.nolink and (conn.getHeader('referer')>'') and not(conn.getHeader('accept')='*/*')
or
section.nourl and (conn.getHeader('referer')='')
) then // it has to exist and be accessible
begin
getPage(s, data, f, me());
exit;
end;
finally free end;
tested with section [style.css|no link|no url] .
-
internal request: <img src="/~img24">
GET /~img24 HTTP/1.1
> Accept: */*
> Referer: http://127.0.0.1/
link request: <a href="/~img24">click</a>
> GET /~img24 HTTP/1.1
> Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, application/xaml+xml, application/vnd.ms-xpsdocument, application/x-ms-xbap, application/x-ms-application, */*
> Referer: http://127.0.0.1/
i think you made something wrong.
the first case, since is an <img>, should have an accept of only images, and not */*.
anyway, i don't understand what you are trying to get.
i mean: what's the need behind this feature?
-
Thank you mars for your proposition. I recognize that i tried to contibute with some idea to what I understood was the subject (how stop section's hacker) of the topic. Only thanks to your poposal I understand that the real subject is that in uppercase letters (ACCEPTED BY THE BOSS). As everything is already accepted, there is no need for me to think about the question.
continue -> continue -> accept -> finish.
-
nothing is finish, bacter, 'ACCEPTED BY THE BOSS' is not at all the end of the topic or the discission, it allows me only to know if the subject which I opened is in process of acceptance or completely refused.
Nothing prevents on the contrary from leaving place with better ideas, so as long is little that they do not make us return behind in the versions of HFS. ;)
-
uh? i don't understand your post bacter.
your suggestion would make it handier, because in a template with 10 sections, you want 8 to be private.
but since it is incompatible with current templates, i noticed that (as solace) you actually need 2 to be private.
notice difference between want and need.
most times, accessing a section that was not meant to be public, causes *no* harm.
-
Rejetto, don't worry about my post. :) It's only a post in this special way that mars and I have developped to communicate with each other ;).
You are right that accessing most sections not meant to be public, cause only garbage on the screen and no harm.
And this few sections that you (or/and) mars propose to declare as private, normally use some extra protection (%user%, memberof, access from ..) preventing execution of not wanted code.
It's not really important if we use [section|private] or [section|local] or [section|public] or {allow|section1 section2 ..}, as long as the final implementation helps to avoid unwanted access to some sections.