We are converting an application that was built in R6 to xpages. In this application, the content was created through the Notes client and viewed on the web. There are a lot of doc links in the documents. Some of the documents have readers fields and that's where theproblem arises.
When looking at a page that contains links to "secured" documents, the URL is something like:
http://servername/dbpath/db.nsf/whaterverdoclinkhere
The links that this page contains all show a URL that looks like this:
http://servername/__REPLICAID/ViewUNID/DocUNID
The problem that we have is that this seems to be considered different DBs from a securitypoint of view and even though the user is logged in when accessing the first page, he gets the login page when he clicks on a link that uses the replica ID of the database instead of its path.
Is there a way to force Domino to use the database path all the time in URLs built with doc links, not the URL with the replica ID?
Related
Recently, we updated the URL for our Sharepoint site. I have added AAMs to direct any users trying to access the site through the old URL to the new URL. So far, everything has been working fine. Recently, while browsing through a document library, I noticed when I clicked on the ellipses on the name of a document so I could copy the link associated to the document, the URL appears as http://NewSiteURl/http://OldSiteURL/...
I notice it is not every single document in my library that presents links like this, but I do notice it in random documents throughout the library. How can I fix this issue so all links to documents within the library so it doesn't contain the old site url?
The context here is that, in a CMS type of app, the users that create content like to reproduce Notes' way of having attachments anywhere in the text, not just a list of attachments at the bottom of the page. When creating a page, they want to be able to create links to the attachments right away, using a link and an img tag, not saving the document first and then edit it again.
I have found the YouAtNotes HTML5 Multi File Upload control, which enables the users to upload the attachments before the document is actually saved. The URL for attachment uploaded befor ethe doc is saved is then:
http://myserver/myDB.nsf/xsp/.ibmmodres/persistence/DominoDoc-NEW_569-Body/indifference.jpg
I use this URL in the CKEditor to create an image and it looks OK: the image shows up in the editor and has this URL:
/myDB.nsf/xsp/.ibmmodres/persistence/DominoDoc-NEW_569-Body/insanity.jpg
I then save the document, and it still looks good. The image is showing up and the URL is still:
http://myserver/mydb.nsf/xsp/.ibmmodres/persistence/DominoDoc-NEW_569-Body/indifference.jpg
I close my browser, and open up the page again, and now I see that my image is not showing up, but the URL is still:
/Belair/xBiblio.nsf/xsp/.ibmmodres/persistence/DominoDoc-NEW_569-Body/indifference.jpg
But if I look at the URL that is used by the download control, this is what is has:
http://myserver/mydb.nsf/xsp/.ibmmodres/domino/OpenAttachment/belair/xbiblio.nsf/E4E384094564EE9E85257F33005953AE/Body/indifference.jpg
Why did it change?
Is there documentation on how that whole attachmentprocess works, so I can understand it and give proper indications to the users so they can create valid links.
We also have a particularity in our publishing code: we need to keep the UNID of the published document so links that were made using UNIDs are still working. It is an app with a lot of content and many external apps link to it. So when we publish, we actually copy all the content of the draft into the already published document, so the UNID is different from the draft document, and we have issues with attachment links because of that. But that is something else...
The URL "/Belair/xBiblio.nsf/xsp/.ibmmodres/persistence/DominoDoc-NEW_569-Body/indifference.jpg" relates to a temporary location before the docment has been saved. This is standard functionality because
For SSJS / Java to save an file into an NSF, it's got to have been uploaded to the server prior to the commit.
The user has not chosen to save the file yet, so it shouldn't be added to the NSF.
The document hasn't been saved yet, so even if it should be saved to the NSF, no document yet exists to save it to.
The components of the URL are:
"/Belair/xBiblio.nsf", the URL of the database it will finally need to be committed to.
"xsp/.ibmmodres/persistence", a URL that corresponds to a physical folder location where temporary files for this NSF are stored, based on xsp.properties of the NSF; if nothing is defined in xsp.properties of the NSF, xsp.properties of the server is used; if nothing is defined there, a default location is used.
"DominoDoc-NEW_569", a temporary reference to the new, unsaved dominoDocument datasource. If you close the browser and re-open it, you'll be getting a different temporary dominoDocument datasource reference, so I wouldn't expect the image to show up. Otherwise, different users could get one another's attachments.
"-Body", the field the file needs saving into.
"/indifference.jpg" the file name.
Once the document is saved, the file is stored into the Body field of the relevant document, and the file system cleaned up. The URL has to change, because otherwise the attachment would not be available on other replicas, because only the database gets replicated, and it could not be managed by DAOS.
The new URL "http://myserver/mydb.nsf/xsp/.ibmmodres/domino/OpenAttachment/belair/xbiblio.nsf/E4E384094564EE9E85257F33005953AE/Body/indifference.jpg" corresponds to:
"myserver/mydb.nsf/xsp/.ibmmodres/domino/OpenAttachment", shorthand URL to open the relevant attachment.
"/belair/xbiblio.nsf/E4E384094564EE9E85257F33005953AE", the location of the document the attachment is stored in.
"/Body", the field name.
"/indifference.jpg", the attachment name (the field could have multiple attachments, of course).
The information above is based on what has been documented in XPages Portable Command Guide (for xsp.properties settings for changing the default temporary locations) and Mastering XPages 2nd Edition.
I'm not sure what the YouAtNotes uploader does, so I can't say whether it should be changing the URL or not on save. But in more recent versions of Domino, attachments can be uploaded without a full refresh, which may be of use as an alternative.
When you're copying documents, if you're storing HTML that references images by their URLs, including UNIDs, you'll need to modify those references.
If you want to keep UNIDs, remember that they are read-write - you can set them as well as get them. However, bear in mind that you'll have problems if you change the URL to the same URL of an existing document. Bear in mind this is also XPages, so the data accessed via the XPages applications don't have to be in the same database.
I want to rewrite the lotus notes workspace using xpages.
So far i am successful but one feature is giving me quit a headache.
How can i access the database icon of a lotus notes application.
I tried to access: http://notespath.mydomain.com/$icon. That problem with that is that
it is not using the login from the current session to access the database and
retrieve the icon. Instead it tries to get it using the anonymous id. If the
anonymous id has no access to the database i get a popup to login.
My question is: Is possible to do this with the user that is logged in to the xpage
or is there is a way to export the database icon into a notes document.
Try following instructions here:
How to extract Lotus Notes database icon?
This should give you a method to get to the DXLExporter, and it looks like the icon is in the IconBitmap object. You're still going to get .ico files out though, which aren't ideal, but could be a good starting point for what you're trying to do here.
As Aaron Brake commented, XPages engine cannot access old Domino URL format for icon. Also see this: Image URL when previewed in Notes and in Web Browser
In our applications we use dedicated 32x32 PNG image resource (img_DBIcon) which is used in XPages. Developers need to maintain this image resource.
What´s about if you change your URL to a database icon??
Don´t use http://notespath.mydomain.com/$icon
Try http://notespath.mydomain.com/DB.nsf/$icon
The tool I'm building needs pull data from IBM Connections Ideation Blogs. I therefore use the Connections API with basic authentication to read Blog Entries. This goes well until the description contains images. When I ask the API to provide media resources for the blog, it does not show any entries of the /BLOGS_UPLOADED_IMAGES location - the one containing images uploaded through the blog's richtext editor. The user I use in my API call is the same user who created blog entries and uploaded pictures.
However the API call DOES contain images I publish using the API and a POST request to the blog's media entry collection. This is where the next problem appears. Those Atom entries for images contain various links, one of them with a ref="enclosure", of which the API documentation (link) tells me to "Use the web address in the href attribute to obtain the binary content of the file". However, my calls to this adress are always answered with 404 response code.
Another url in the Atom entry (this time of the element) is described by the same documentation (see link above) as: "Provides access the document's media. The following operation is supported: GET: Use the web address to obtain the media." When I make a call to this url, as always with basic authentication credentials attached, the response contains the html of the login form of Connections, so API authentication does not seem to be supported on this url. This is only the case for non-public communities, which require authentication, of course, if the picture is publicly availabe all works just fine.
Am I missing something out? Is there another way to retrieve the actual image from a blog's media entry through the API? Are manually uploaded pictures never contained in the media entries result or is this a bug?
It now magically works using the link with ref="enclosure" from the atom entry. I might have gotten something wrong with authentication I guess (although I'm not actually realizing what I'm doing different now than I did before).
Problem remaining: Pictures uploaded through the rich-text editor in the folder /BLOGS_UPLOADED_IMAGES do not appear in the media feed of the blog.
Am developing my first Xpage application and have designed a login screen in domcfg.nsf. So when user types my url like Myrequest.com(dummy url) this should redirect me to the login page and then on succesful login attempt the page should be redirected to Myrequest pplication. Could you please let me know how to configure in server document or Internet site document. ?
As a first step,I executed the below points.
Enabled Load Internet configurations from server/Internet sites
documents in the basic tab of server document.
Created new web site document by clicking on web>>Internet sites Web
Site-Basic Tab::
a. Descriptive name for this site :myRequest.com;
b. Organization: testCompany;
c. Use this web site to handle requests which cannot be mapped to any other
web sites: NO ;
d. Host names or addresses mapped to this site: my local ip address;
e. Domino server that host this site : *
In Web Site-Configuration Tab::
a. Home URL : /myApp/myRequest.nsf?open
The rest of the configuration are all default's
When I tried opening myRequest.com no page is displayed. I guess i have made a mistake. Do i have to change any configurations ?
The way this works is:
Set up an internet site (remember to check that your Domino server is using internet sites (first tab in the server document)
The internet site should not contain any information about login - just the right path etc. for the domain/subdomain to point at the right page in the right database (and possibly url redirections, headers, etc.)
Now create the login form, e.g. in your application database (or any other applicable database). Make sure that you have the right fields on it for the login to work - and any error messages to be correctly shown. The easiest way is to look at the standard login form (its called "$$LoginUserForm") found in domcfg.nsf (if domcfg.nsf does not exist, just create it with that name based on advanced template "Domino Web Server Configuration (8)" (template file: domcfg5.ntf)
Now create a Sign In Form Mapping document in domcfg.nsf. Select the specific domain/subdomain that it applies to (or a default for all websites not using another specific sign-in form), specify the path to the database with the form (e.g. your application database), and specify the name of your login form in that database
Now you just need to turn on the mechanism that will require your users to log in. This is done in the ACL of your database. When a user is not logged in it will obey the rules of a person entry with the name "Anonymous". If this "person" is not present in the ACL it will of course obey the default settings. You will have to determine when you want your user to log in. If you specify "No Access" then you may have to set "public read" on some of your design elements for the login form to display properly (e.g. graphic files etc.) and then you should also allow the Anonymous person to read public files (in the ACL). You may also want users to be able to read content and only be forced to log in when they want to write/change something, in which case your Anonymous user would be reader and default (or a specific group, etc.) would be author/editor - but that is all about standard Domino security/ACL and not related to web/XPages ;-)
/John