I have a RESTFul WCF service with a url likes this
groups/{groupName}/members
which returns a list of users this works fine for normal groupNames. But when I use a groupName with a special char (like #) nothing is returned
ex.
when the url
groups/c#/members
is called from the client it only returns null.
I put a break point in the service code but the service's method is not even executed.(Break point never gets hit)
Also I tried using the url encode to encode c# as c%23 but the result is still the same. I tried this with built in web server of VS 2010 and IIS 7 but the result is still the same.
And I am using .NET 4.0
Any help will be really appreciated
In a url the hash indicates the end of the url and what follows it is a reference to a specific portion on the page, so the url /groups/c#/members is interpreted as the url /groups/c (and then the browser tries to take you to the href on the page named "/members".
Basically you should never allow # as a character in your dynamic url's. There's a reason people generate permalinks with only alphanumeric characters separated by dashes, and it's not just for readability/SEO. Some characters just plain aren't allowed. You should look at having a permalink field in your application so groups might have a name of c# which you display on page, but also a url friendly version of the name like c-sharp.
Related
I have a page tab app that I am hosting. I have both http and https supported. While I receive a signed_request package as expected, after I decode it does not contain page information. That data is simply missing.
I verified that like schemes are being used (https) among facebook, my hosted site and even the 'go between'-- facebook's static page handler.
Also created a new application with page tab support but got the same results-- simply no page information in the signed_request.
Any other causes people can think of?
I add the app to the page tab using this link:
https://www.facebook.com/dialog/pagetab?app_id=176236832519816&next=https://www.intelligantt.com/Facebook/application.html
Here is the page tab I am using (Note: requires permissions):
https://www.facebook.com/pages/School-Auction-Test-2/154869721351873?id=154869721351873&sk=app_176236832519816
Here is the decoded signed_request I am receiving:
{"algorithm":"HMAC-SHA256","code":!REMOVED!,"issued_at":1369384264,"user_id":"1218470256"}
5/25 Update - I thought maybe the canvas app urls didn't match the page tab urls so I spent several hours going through scenarios where they both had a trailing slash or not. Where they both had a trailing ? or not, with query parameters or not.
I also tried changing the 'next' value when creating the page tab to the canvas app url and the page tab url.
No success on either count.
I did read where because I'm seeing the 'code' value in the signed_request it means Facebook either couldn't match my urls or that I'm capturing the second request. However, I given all the URL permutations I went through I believe the urls match. I also subscribed to the 'auth.authResponseChange' which should give me the very first authResponse that should contain the signed_request with page.id in it (but doesn't).
If I had any reputation, I'd add a bounty to this.
Thanks.
I've just spent ~5 hours on this exact same problem and posted a prior answer that was incorrect. Here's the deal:
As you pointed out, signed_request appears to be missing the page data if your tab is implemented in pure javascript as a static html page (with *.htm extension).
I repeated the exact same test, on the exact same page, but wrapped my html page (including js) within a Perl script (with *.cgi extension)... and voila, signed_request has the page info.
Although confusing (and should be better documented as a design choice by Facebook), this may make some sense because it would be impossible to validate the signed_request wholly within Javascript without placing your secretkey within the scope (and therefore revealing it to a potential hacker).
It would be much easier with the PHP SDK, but if you just want to use JavaScript, maybe this will help:
Facebook Registration - Reading the data/signed request with Javascript
Also, you may want to check out this: https://github.com/diulama/js-facebook-signed-request
simply you can't get the full params with the javascript signed_request, use the php sdk to get the full signed_request . and record the values you need into javascript variabls ...
with the php sdk after instanciation ... use the facebook object as following.
$signed_request = $facebook->getSignedRequest();
var_dump($signed_request) ;
this is just to debug but u'll see that the printed array will contain many values that u won't get with js sdk for security reasons.
hope that helped better anyone who would need it, cz it seems this issue takes at the min 3 hours for everyone who runs into.
We are using the Google places API in our application... it searches
for the address correctly.
But when the address contains some special characters, e.g. "#101"
etc, it fails with a REQUEST_DENIED error. Whereas the same address
works fine on the Google maps website.
I have verified that my API key, URL, Address, Sensor parameter etc.
all are correct. The same query starts to fail when we add special
character # in the query.
I have also tried the javascript's encodeURL function but had no
benefit. I have also tried replacing # sign with # but had the
same result.
Example URL
Please help.
As an example, the Rails parameterize method would create a string like so:
"hello-there-joe-smith" == "Hello There Joe.Smith".parameterize
For legacy reasons, a project I am working on requires uppercase letters as well as periods to be available in a particular URL parameter.
Why would this ever be a problem?
Clarification
The url type I'm talking about is what is used instead of an id, commonly knows as a slug.
Would a Rails app with the following url come to any issues: http://example.com/Smith.Joe?
This will be a problem both in terms of SEO and browser caching (and hence performance,)
Search engines are case sensitive, so same URL in different case will be taken as two URLs.
Browser like IE's caching is case sensitive, so eg. if you try to access your page as MYPAGE.aspx and at some place in code, you write it as mypage.aspx then IE will treat them as two different pages and instead of getting it from cahce, it will get it from server.
Dashes should be fine but underscores should be avoided : http://www.mattcutts.com/blog/dashes-vs-underscores/
I'm trying to achieve urls in the form of http://localhost:9294/users instead of http://localhost:9294/#/users
This seems possible according to the documentation but I haven't been able to get this working for "bookmarkable" urls.
To clarify, browsing directly to http://localhost:9294/users gives a 404 "Not found: /users"
You can turn on HTML5 History support in Spine like this:
Spine.Route.setup(history: true)
By passing the history: true argument to Spine.Route.setup() that will enable the fancy URLs without hash.
The documentation for this is actually buried a bit, but it's here (second to last section): http://spinejs.com/docs/routing
EDIT:
In order to have urls that can be navigated to directly, you will have to do this "server" side. For example, with Rails, you would have to build a way to take the parameter of the url (in this case "/users"), and pass it to Spine accordingly. Here is an excerpt from the Spine docs:
However, there are some things you need to be aware of when using the
History API. Firstly, every URL you send to navigate() needs to have a
real HTML representation. Although the browser won't request the new
URL at that point, it will be requested if the page is subsequently
reloaded. In other words you can't make up arbitrary URLs, like you
can with hash fragments; every URL passed to the API needs to exist.
One way of implementing this is with server side support.
When browsers request a URL (expecting a HTML response) you first make
sure on server-side that the endpoint exists and is valid. Then you
can just serve up the main application, which will read the URL,
invoking the appropriate routes. For example, let's say your user
navigates to http://example.com/users/1. On the server-side, you check
that the URL /users/1 is valid, and that the User record with an ID of
1 exists. Then you can go ahead and just serve up the JavaScript
application.
The caveat to this approach is that it doesn't give search engine
crawlers any real content. If you want your application to be
crawl-able, you'll have to detect crawler bot requests, and serve them
a 'parallel universe of content'. That is beyond the scope of this
documentation though.
It's definitely a good bit of effort to get this working properly, but it CAN be done. It's not possible to give you a specific answer without knowing the stack you're working with.
I used the following rewrites as explained in this article.
http://www.josscrowcroft.com/2012/code/htaccess-for-html5-history-pushstate-url-routing/
I'm writing a website for a local club of ours. I've got all the site written in ASP linked to our backend SQL server and it works lovely. I want to create player profiles now. Normally I would use "(a href=playerdetails.asp?ID=1) Player 1 (/a)" then in the ASP section of the page use strsql = "SELECT * FROM Players Where ID=" & request.querystring("ID").
However, this is where my problems starts. To save money for the club, I am also hosting the site for them on my private domain. We have registered there domain and instead of paying for hosting, we're just redirecting the traffic via the domain registers URL forwarding, using masking. Therefore instead of the URL saying www.mydomain.com/club/ it says www.club.com.
Thus the original question... Can I use request.querystring with the setup we have? If not, is there a way around it as the club doesn't really have the budet for a hosted site with SQL in the backend.
Thanks in advance,
Paul.
PS <'s in the link replaced with ('s to display correctly.
A couple of things:
URL Masking uses frames to hide the actual URL. You can still use query string values in the URL, however you will not see the URL in the address bar change, because it will always be www.club.com do to the URL masking.
http://en.wikipedia.org/wiki/Domain_Masking
Second you are opening up your site to SQL injection attacks:
NEVER trust user input
NEVER use Request.QueryString or Request.Form in SQL states without filtering out bad characters and keywords.
http://en.wikipedia.org/wiki/SQL_injection