Welcome!

Welcome to the official BlackBerry Support Community Forums.

This is your resource to discuss support topics with your peers, and learn from each other.

inside custom component

Web and WebWorks Development

Reply
Contributor
scottolle
Posts: 17
Registered: ‎02-24-2010
My Device: 9700

Authentication in the Visual Studio Plug-in

Windows 7 Ultimate 32 / Visual Studio 8/.NET ASP web server

 

I have been working with the XMLHttpRequest and while I am having to make completely new server side pages to call, it is working.  One odd-ball thing is that the "document" that gets retrieved has the CSS tags, but the CSS files don't come over.  However, having the same CSS files on the plug-in side does the trick.

 

I have been struggling for some time now.  I have some test code that I run against a IE browser, all JavaScript using XMLHttpRequest.  I have one button that calls the external web site and authenticates.  Then because it is using the same request object, any future requests to other pages know from where it came so they are authenticated because it knows the context of the connection. 

The same pure JavaScript code does not work in the plug-in.  The connection only seems good for one request or at least the server doesn't know that it just made a recent request and the connection context is no longer there.  I don't know what it is doing internally.  My work around is that I I am having to pass the uid and password in the query string  or every page request an customize the pages on the server to look fo the query string and reauthenticate every page.  I don't feel very good about this... I can do things like SSL, look at the browser and only allow this when it comes from a BB plug-in etc, but this seems very tedious.

Does anyone have any sample code or can you point me to the right direction for basic authentication and keeping persistent connection or cookies or something using the XMLHtpRequst framework in the web widget plug-in environment?

Regards,

Scott

New Developer
devbuzz
Posts: 4
Registered: ‎02-03-2010
My Device: Curve 8900

Re: Authentication in the Visual Studio Plug-in

Scott, not sure if this helps or not but I've been having a tough time getting the blackberry browser to persist forms authentication cookies. I spent about a day and half on it and eventually gave up. I ended up using ASP.NET Session vars for some limited security.

 

This was my original post:

http://supportforums.blackberry.com/t5/Web-Development/Does-the-BB-support-Forms-Authentication-ASP-...

 

Contributor
scottolle
Posts: 17
Registered: ‎02-24-2010
My Device: 9700

Re: Authentication in the Visual Studio Plug-in

 

Thank you for your response...I was wondering if you could give me a little more detail on your approach.

 

 I have started looking into it... So is the idea you use the httpcontext.curent and reset the variables i.e.. user.idnity.name and is authenticated =true if they are not ?  It seems like under the plug-in environment it losses the session variables after the request where a regular browser (20 minutes or so) it keeps them for a while as long as you are in the browser.  The BlackBerry browser keeps the context around, because I can run the same pages after the forms authenticaton page and it works like normal.

 

I see in the C# reference how you can gain access by the variable and read and reset them in your page "session" or "httpcontext.current".

 

I can't find a way to set the httpcontext.current in JavaScript which is all we have access to under the plug-in widget environment.  So are you hiding variables in a form and posting them?... And if you are you would still have to modify the server app to pickup the vars and reset them from something you pass in your request....

 

Sorry to bother you... I can see how I can pick them up or reset them directly in C#, but I am not understanding how you are passing or setting them from within the BlackBerry environment, and I feel like sending authentication params through the querystring is bad practice and maybe insecure even with SSL.

 

Thanks again for your response,

Scott