Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

  • Isomorphic
    replied
    It has already been logged as such.

    Leave a comment:


  • Blama
    replied
    Hi Isomorphic,

    something like secure="true" and/or <secure-extension> would be enough for me.
    Can you log this as enhancement?

    Thank you & Best regards
    Blama

    Leave a comment:


  • Isomorphic
    replied
    The extension mechanism was designed primarily for tags that drive client-side component behaviors and/or mixed client/server behaviors (like our validators). Right now there is no way to embed secure information then later strip it out. A working approach would be to embed identifiers referring to secure information stored elsewhere, or even have a SQLDataSource subclass where all instances look up additional information stored elsewhere under the dataSourceId, or more granularly, by dsId.fieldName.

    You could also propose a Feature Sponsorship here; it would be quick to allow a uniform tag like <secure-extension> that would cause all children to be omitted or an attribute like secure="true" that would cause a marked tag to be omitted. Something involving XPaths or transforms could also be possible, though more involved.

    Leave a comment:


  • Blama
    replied
    Hi Isomorphic,

    reading this thread and thinking about the whole topic I do have an improvement suggestion, that actually might be really necessary.

    You do say that the .ds.xml is extensible here (and also in the QSG IMHO) and I start to grasp the power of it only now:
    • I do already use it to document meaning for fields and generate an XML+XSL-documentation
    • I'll move MANY boilerplate Java DMI to .ds.xml and my SQLDataSource-subclass)
    • I'll also use it to circumvent DB limitations (I want to display 1:n entries in a ListGridField using a DB-View with Oracle-ListAgg, but this just fails with an DB error, if there are too many linked entries (works for less entries) in 11.2 and you can't do anything about it (changed in Oracle 12 with ON OVERFLOW TRUNCATE, but I'm on 11.2)
    My own existing documentation tags should of course not be sent in the DataSourceLoader response, because they will clutter it A LOT.
    The ones I want to introduce to solve the ListAgg problem will include table name and column names you would remove it from the DSL-result for security reasons like you did for nativeName if it were a built-in feature.

    So I somehow need a way to specify which tags to remove. Perhaps in server.xml as XPath or similar?

    Does this make sense to you?

    Best regards
    Blama

    Leave a comment:


  • Blama
    replied
    Hi Isomorphic,

    just to confirm: Using current 12.0p I don't see any "nativeName" anymore in my DataSourceLoader result.

    Best regards
    Blama

    Leave a comment:


  • Isomorphic
    replied
    OK, it looks like the bug is that nativeName is not removed automatically if you happen to have disabled this feature. We'll address this shortly.

    Leave a comment:


  • Blama
    replied
    The last line in my server.properties is: datasource.autoLinkFKs: false

    Leave a comment:


  • Isomorphic
    replied
    Have you turned off dataSource.autoLinkFKs?

    Leave a comment:


  • Blama
    replied
    Hi Isomorphic,

    I think think so. This is my .ds.xml header:
    Code:
     <DataSource xmlns="lmscompany/ds" xmlns:fmt="lmscompany/fmt" dbName="Oracle" tableName="xxx" ID="xxx"
      serverType="sql" serverConstructor="com.lmscompany.lms.server.LMSSQLDataSource" progressiveLoading="true">
      <fmt:bundle basename="com.lmscompany.lms.server.i18n.DSXMLResources-utf8" encoding="utf-8" />
    Does this already help?

    Best regards
    Blama

    Leave a comment:


  • Isomorphic
    replied
    Is it possibly you've specified "nativeName" for a DataSource that is not actually a SQLDataSource? Or perhaps that you've got a SQLDataSource, but your .ds.xml file does not say serverType="sql" because you've got a custom DataSource that subclasses SQLDataSource? It looks like that latter case may not be covered, whereas for normal cases we are seeing nativeName being removed.

    Leave a comment:


  • Blama
    replied
    Hi Isomorphic,

    Originally posted by Isomorphic View Post
    The DataSourceLoader already automatically removes all sensitive information from the DataSource descriptor as it is delivered to the browser.
    as you can see in this thread, nativeName is not removed from the response in v10.1p_2017-07-04. I think that it like tableName or customSelectExpression, etc. should never be transmitted to the user.

    Please note that this thread is also about unneeded data in the DataSourceLoader response.

    Best regards
    Blama

    Leave a comment:


  • Isomorphic
    replied
    The DataSourceLoader already automatically removes all sensitive information from the DataSource descriptor as it is delivered to the browser.

    We're not sure why your output shows tableName and schema - those are automatically removed and have been for a very long time. But perhaps you are using server .jars from an even older version than 2.4. Regardless, updating to a recent version will fix this problem.

    Also note that Blama did not suggest making any changes. No work is required for sensitive information to be automatically removed.

    Note that, with the sensitive information removed, the rest of the information is the same structural information that is revealed as soon as you show an end user the grid or form bound to the DataSource. It's not an information leak.

    @Blama please start a separate thread about your tableCode/columnCode questions.

    Leave a comment:


  • Blama
    replied
    Hi Aparajita,

    let's wait for Isomorphic, but I'd assume that this is not possible.
    The client side needs to know about the DS and needs to "speak the same language" as the server. SmartGWT with client and server components won't work without the DSLoader-servlet.
    The URL you called can be called by everyone in a browser, just like you did and you won't be able to stop this.

    What should work is the following: If you use session management of Tomcat/your servlet engine, you could make sure that the DSLoader-servlet is protected and can only be accessed by logged-in users. See Isomorphic wiki.

    If you decide to change the DS IDs I'd suggest to use a Enum to collect as DS and use it *always* like this: DataSource.get(enum.getValue());. That way you can change DataSource IDs more easy and can as well find usages of the DataSource easy with your IDE - that would not be possible with just Strings.

    Best regards,
    Blama

    Leave a comment:


  • aprajita
    replied
    Hi isomorphic,

    Is there any other way to get stop printing response of datasource loader servlet??
    Blama suggestion will be work intensive task and changing each ds.xml is quite complex and may not be accepted in security review.

    Any other ideas/solution may be helpful to resolve this critical issue as this is security concern .

    Thanks,
    Aparajita

    Leave a comment:


  • Blama
    replied
    Hi Isomorphic,

    why am I getting the tablecode / columncode in the result anyway?
    I never use autoDeriveSchema in my .ds.xml (v9.1p_2014-08-11, Oracle database).
    I don't think I need them and they increase the uncompressed size of the result from 230kb to 280kb.

    Is there some setting that enables autoDeriveSchema by default?

    Best regards,
    Blama

    Leave a comment:

Working...
X