jQuery Forum

> The alert below never occurs (and a breakpoint is never hit if I put
> it there), but I can see that the ajax request is being sent.
>
>                 j$.ajax({
>                         'url': serviceUrl,
>                         dataType: "jsonp",
>                         data: params,
>                         beforeSend: function(req) {
>                            alert("inside!");
>                         }
>                 });
If serviceUrl is on a different domain then your jsonp request will
not use ajax, and so beforeSend will not be called. x-domain jsonp
requests inject script tags into the document head.

Yes, it is on a different domain (which is why jsonp is being used). What strategy would you suggest for me to be able to specify headers? It's a must-have for my application.

> Yes, it is on a different domain (which is why jsonp is being used). What
> strategy would you suggest for me to be able to specify headers? It's a
> must-have for my application.
You can't. Are you saying you're trying to access a jsonp service
that requires specific request headers on the GET request? Are you
sure there is no url parameter alternative to the required header?

That's correct, the problem is that it's an authentication service and while I <i>could</i> put the credentials on the URL, it would be sending them in the clear across the internet, which is not acceptable. 

> That's correct, the problem is that it's an authentication service and while
> I *could* put the credentials on the URL, it would be sending them in the
> clear across the internet, which is not acceptable.
That's a tough one. A typical jsonp implementation uses either iframes
or (in jQuery's $.ajax case) a dynamically-inserted script tag.
Neither allows you to affect the header that's sent. And of course
XMLHTTPRequest lets you jiggle headers but doesn't allow cross-domain
requests.
Are you implementing your own cross-domain authentication service, or
are you using some other service?

It's our own existing auth service (and I'm not on the implementation team). Most other usages of this service are not directly from the browser, but from the back-end via java. I thought about proxying it via my service, but my service isn't SSL, so proxying still doesn't give me security anyway. I guess now I'm thinking maybe a small Flash component could be used to obtain the security token, as a cross-domain.xml installed on the server will allow Flash to cross domains. Not ideal.

> It's our own existing auth service (and I'm not on the implementation team).
> Most other usages of this service are not directly from the browser, but
> from the back-end via java. I thought about proxying it via my service, but
> my service isn't SSL, so proxying still doesn't give me security anyway.
You might want to discuss it with the auth service team, it sounds
like they haven't anticipated this type of usage.