I have a need to integrate a third-party Java applet into a custom web part I wrote for SharePoint 2007. The web part simply loads a user control I created that contains the bulk of the functionality, and that's where the applet will go. I added it to my user control project and it works fine outside of my SharePoint environment.
I installed the updated web part onto my MOSS 2007 development site and the part's page loads fine. The applet is triggered by clicking a link button on the page, which runs some client-side JavaScript to start it. The problem is nothing seems to happen when I click the link. No error messages appear, and the stuff the applet is supposed to do never occurs (it's for doing file transfers via FTP). I have the .jar file as an embedded resource in my user control DLL, which is deployed to the bin folder, and SharePoint fully trusts this DLL.
I used Firebug to step through the initialization code and I saw an HTTP GET that failed with a message about not being authorized, but it didn't give any details and I'm not positive it was related to the applet.
Is there anything special I need to do to make the applet work? Or am I going about this the wrong way?
EDIT: The problem turned out to be the .jar file for the applet couldn't be found. SharePoint is clearly doing something different here, and I need to find out what. Can Java applets be used within a SharePoint site? This question suggests they can, but in that case a Page Viewer web part was used, which isn't going to really work for me.
An applet in HTML is handled by applet/object tag. Your webpart should just render the OBJECT/applet tag and its attributes relevant to the applet (code, height, width) or you can let the JavaScript do it all and your webpart can provide the marker div where the applet needs to be rendered. That's about it and Sharepoint does not have to have any more knowledge about the applet since it is all taken care of the browser. The archive parameter points to the jar that can be located on your server than should be browsable. Instead of bundling it as a resource in the DLL , host it on the server just outside of the Sharepoint website. You might have to create a virtual directory in a different website for the same. This simplifies the deployment model.
It is possible the applet make a HTTP call back to the SharePoint site and it does not pass any credentials
Related
Alright I am a bit of a newb when it comes to ASP.net. I am used to PHP.
Anyway, I am working on a website that is connected to my server via ftp. Everything is working fine, except I just added some classes in the App_Code folder. I cannot access those classes when I go to the page on the web.
I was researching a bit and everyone said I needed to publish the website. Well I did that, and it completely broke. I had to restore from a backup and lost a lot. My own fault though.
The classes work if I am using them on a local web site, but not on the web. Any guidance here? I've tried moving the App_Code folder around with no luck.
the web server doesnt directly execute a .cs file like a .php file. a web server has registered handlers associated with a file extension. when a request arrives, the extension of the file is used to find a dll to process the request. the asp.net web pages model is an easy onramp for people coming from php. http://www.asp.net/web-pages
Can I have a ribbon button launch an aspx ( asp.net ) page? The aspx page needs to inherit authentication and authorization as the logged in Dynamics user.
You can execute custom JavaScript from a ribbon button allowing you to spin up a new browser window pointing at whatever you like.
To inherit security credentials you need to look at setting up federated authentication across both the CRM server and the custom website hosting the ASPX. As you can probably imagine this isn't a trivial task.
You could also look at dropping your website into the custom ISV folder as was the case with CRM 4. However, this approach has been deprecated in CRM 2011 and AFAIK is therefore no longer supported.
As #Konrad pointed out you won't be able to use the Data Service REST API (OData) from your custom web pages as the service is only accessible from web resources hosted within the CRM environment. Server-side you'll be fine against the Org Service.
If you can get away with doing what you need in a web resource I'd highly recommend it as it's a whole lot less work.
I'm not sure you can do that. A while ago, I put in an iframe that I linked to an outside web page and it worked as supposed to except for connecting to the organization data. I just couldn't make that work (I got impatient, to be honest and didn't try all too hard).
The resolution I deployed in the end was to run a web resource, which was run internally on the server, that communicated the data to an outside service.
I'm assuming that the same behavior will follow if you try to open windows/convey data in to/out from the CRM.
I have a question about hiding or encoding the source code on a server which runs IIS.
At the moment the source code is available and visible for all users who are logged into the server where the IIS Server is running.
Is there a way to hide the Code (encode) with Visual Studio or any other software?
I think the aspx (or *.html) web site code can not be encoded but (for example) the *.vb code sites should be able to encode.
You can simply Publish the website
Build Menu => Publish Web Site
So the code behind files (*.aspx.cs) will get converted to dll(Bin/*.dll) file.
Refer this: Walkthrough: Publishing a Web Site
When you are ready to put your project live make sure that you.
Publish it.
When you publish it that you tell it to compile your code into a single library or code behind files.
If you want to protect your html as well then you should not select to make the site updateable.
These steps will protect your code but as for your web.config file you will need to look at some other articles on securing its info.
If you can, I would recommend ensuring that only the authorized people have access to the server and/or the code base running on the server. If that is the case then you should be ok.
Go to Build menu---> Click on Publish the Website.
then a folder get created on the base folder. and the encoded files are available there. That can be upload to the FTP account, then third party can't see the source code with the browser.
I downloaded the file discussed in this article and tried "dropping it into" a production web site, but got the following error when I tried to access it through my Web browser:
[HttpException (0x80004005): The file '/WebResources.aspx' has not been pre-compiled, and cannot be requested.]
If I drop the file into webs on my local machine, it runs fine. How do I pre-compile this single file without re-publishing the whole application? Is there something that I can do to pre-compile just this one page. (Note: It doesn't reference any external controls, Masterpages, etc.)
One lazy solution for your problem (without checking the source of the error) is to view the page inside an iFrame.
<iframe src="/WebResource.aspx" width="100%" height="100%">Your browser does not support iFrame</iframe>
but if you need that page to interact with controls outside of its scope, then you will need to look into the header part of the ASPX and make sure that it inherits from the proper class, and is part of the Web Project that is calling the page.
This is pretty easy to do.
Put the file into it's own web application project.
Publish the project to a local directory.
Copy the file and associated assembly to your existing web application. Take care NOT to overwrite your web.config.
Done. This new file now has access to everything your other web app does.
I am creating a standalone asp.net page that needs to be embedded into a sharepoint site using the Page Viewer Web Part. The asp.net page is published to the same server on a different port, giving me the URL to embed.
The requirement is that after a user is authenticated using Sharepoint authentication, they navigate to a page containing the asp.net web part for more options.
What I need to do from this asp.net page is query Sharepoint for the currently authenticated username, then display this on the page from the asp.net code.
This all works fine when I debug the application from VS, but when published and displayed though Sharepoint, I always get NULL as the user.
Any suggestions on the best way to get this to work would be much appreciated.
If you want to retrieve the currently authenticated user from the SharePoint context, you need to remain within the SharePoint context. This means hosting your custom web application within SharePoint (see http://msdn.microsoft.com/en-us/library/cc297200.aspx). Then from your custom application reference Microsoft.SharePoint and use the SPContext object to retrieve the user name. For example:
SPContext.Current.Web.CurrentUser.LoginName
You can still use the Page Viewer Web Part to reference the URL of the site, now located within the SharePoint context.
Thanks heaps for the answers!
Turns out that as long as the asp.net page is using the same URL and port as the Sharepoint site, authentication works across both sites.
The solution is to use a Virtual Directory inside of the sharepoint site and install the asp.net page there.
When it works in debug, is that being used in SharePoint?
Your page and the Sharepoint site might as well be on different servers as far as authentication is concerned -- in order to get the information over you might need to pass it via the QueryString from the webpart if you can -- or you might need to make your own webpart to do this (just put an IFRAME in the part with the src set to your page with the QueryString passing the username).
It does seem that this would be a security issue if you use the name for anything though -- if you are just displaying it, then it's probably fine.
If you actually need to be authenticated, you might need to add authentication into the web.config of the site hosting your standalone page.
edit: I think you'd have better luck putting your page on the same port and server as SharePoint.
I suspect you will have a hard time specifically querying SharePoint for the currently authenticated username. I can't think of a way to easily access the SharePoint context from a separate web application like you are describing.
I don't know what kind of authentication scheme you are using, but you may want to consider using Kerberos, as I've found that it can make these kinds of scenarios a little easier by allowing for delegation and passing credentials from application to application or server to server.