very often in Internet I see links like this:
www.abcde.com/~main/material/hello
and this part ~main/material/hello is grey, if I remove hello I receive access forbidden, can somebody explain, what is this system, and is it possible receive access?
Directory listing is disallowed on www.abcde.com/~main/material/, but you have access to it's content.
They've configured the web server to only allow access to certain areas. You won't be able to receive access to it.
Depends on the web server. On Apache this can be done with
Options -Indexes
what do you mean it is grey? the link text on a page? That can be any colour that the page owner wants, but I don't remember seeing a grey link.
What happens if you type www.abcde.com/~main/material/hello directly into the browser's address window?
If you remove "hello" and receive access forbidden it is because there is no public access to www.abcde.com/~main/materia - give up, you will never access that without a password.
The tilde (~) is *nix convention for a user's home directory. Using it in the URL tells an appropriately-configured web server to look in a directory in the user's home directory for the files to show via the web server.
Related
I am trying to get a simple CGI website set up with Perl that creates an HTML page that links to a Java applet. I have managed to set this up, but for some reason, the Apache authentication for the site is doing some wonky things. Namely, if the password was entered incorrectly, instead of redirecting to a 403 page (as I assumed it should), it just refreshes the page - bringing up the password prompt again. My htaccess file looks as follows:
AuthUserFile PATH/TO/HTPASSWD
AuthGroupFile /dev/null
AuthName NAME
AuthType Basic
require user USER1
and it is located in the Java applets directory (different from the CGI directory). I have been looking around as to why this problem occurs, but I can't seem to find a reason the page would be refreshed. Does anyone know if this behaviour is typical if a Perl CGI program is trying to access an applet with .htaccess in the applet folder? Thanks beforehand.
It returns the more appropriate 401 Unauthorized error. The response includes the authentication method (Basic). Browsers respond to that by displaying a login prompt. (I believe the browsers give you a 401 error page after a few attempts.)
This is appropriate behaviour. You want to the user to be given another chance to enter his user/password. The real problem is that you can't customize the error to include other links (for example). The name "Basic" is merited.
I have just created a new facebook application to use in a page tab. When I check for the signed_request it is empty.
So I checked another app that I have done in the past. It is on the same server and the only difference in the setup is the dir name.
http://example.com/app1/ works
and
http://example.com/app2/ doesn't
So I tried swapping the tab URLs in the apps over and app1 still works with app2s URL.
This lead me to believe there must be a problem with the way I have set up the application.
So I went through all the settings and made sure they were the same. They all are, except there are 2 that are not available on the app I just setup. They are "Encrypted Access Token" and "Requests 2.0 efficient" neither of which seem to relate to the problem.
I seem to remember in the past there was an option to pass through the signed request to canvas page, but I can no longer find it.
Has signed request been deprecated? I couldn't see any mention of that in the docs.
Any help/comment appreciated. Otherwise I am going to have to go back and re-use old apps with new content in them, and I only have about 15 more before I run out.
Cheers
Alex
No, it wasn't deprecated.
There can be 2 issues that could cause this
You must have a trailing slash or a specific file on your page tab url.
http://myapp.com/app/
http://myapp.com/app/index.php
Your server for the second app is redirecting the request which causes it to lose the POST variables.
You should check if there aren't any redirects which usually occur form mod_rewrite. (.htaccess and such)
This seems to have been resolved now, I can no longer replicate it with new applications.
I have a page on my DotNetNuke site and I would like to set up a redirect and was wondering the best way to do it. Here is the problem:
I have a page on the site: mydomain.com/dashbaord.aspx. I would like users to be able to type mydomain.com/dashboard OR mydomain.com/Dashboard and it will redirect them to the /dashboard.aspx page.
I have IIS6, so I set up wildcard mapping, and it seemed to work for /dashboard, but not /Dashboard. Also, I am looking for it to literally redirect you so that /dashbaord.aspx shows up in the address bar. In addition, the wildcard mapping broke some other links on the site, so I was looking for an alternative method to accomplish this. Is there a way that I can set this up through IIS? Or any other way?
Thanks in advance for the help.
In IIS, create a virtual directory by right clicking on Sites, and then call it Dashboard. Then set that to redirect to a specific URL, in your case, http://mydomain.com/dashboard.aspx.
Upon install of my app on a Facebook Page, I'd like to send the user to an URL with further instructions. I'm starting the installation with http://facebook.com/add.php?api_key=app_api_key&page=page_id, which installs but redirects the user to the Facebook Page itself. It seems like various forms of redirect were available at some point:
Post-authorize callback URL. I can no longer find that in App settings.
The next parameter for add.php. I can't seem to get this to work
I have seen some apps that do redirect upon install, so I believe this is possible. Maybe it's using an old Post-authorize setting that's no longer visible?
Any help or point would be greatly appreciated! I'm also not attached to using add.php, if there's a Facebook Connect method that does this I'd use that instead (I'm looking at profile.addtab though that doesn't seem to work either).
You can set the redirect URL in the app properties. You can no longer set it from the developer control panel in Facebook, but you can still set it using the REST api.
The list of app properties is here: http://developers.facebook.com/docs/appproperties/
To set the "post_authorize_redirect_url" you would use something like this:
https://api.facebook.com/method/admin.setAppProperties?
access_token=CURRENTTOKEN&
properties={'post_authorize_redirect_url':'http://mydomain.com/post_authorize_folder/'}
I am not completely clear on this, but I believe the url needs to point to a folder, terminated with "/" rather than a specific file.
The callback gets two parameters:
installed = 1 (true)
fb_page_id = the page id when your app was installed
First page that Canvas is point to should have
< script type='text/javascript'>top.location.href = 'REDIRECT-URL';< /script>
So when your app is opened it will automaticaly redirect to REDIRECT-URL
I'm not sure that you can avoid opening of application canvas page after installing application.
A customer site that I cannot change has the line document.domain = "example.com" while the site is at www.example.com.
The effect is that FaceBook Connect window login gets stuck after submitting username+password.
Firebug shows its in infinite loop inside dispatchmessage function, which gives perpetual exception:
Error: Permission denied for <http://www.example.com> to get property Window.FB from <http://example.com>
Any idea how to work around this? I prefer not to ask the customer to remove the document.domain='example.com'
It seems like a really bad idea to tell the visitor's browser that the website is being served from a particular domain, when it in fact is not. The best solution would be to change that line. I take it you don't want to change it because they have some client-side code that depends on this?
One workaround would be to change the Facebook application's Connect URL to http://example.com, since Facebook's JavaScript will think that is where it is being executed.